Stupid question about programming games

A

alec

White heterosexual male
Orderite
Here goes:

Is it right to assume that in a game like Fallout, there is a program controlling the world (the environment) and a different one controlling the character(s), each with their own logic, parameters, code, ...?

If so, is this the case for all games (3D as well)?

Do small, animated objects also have their own code/program (e.g. a pit of fire, an aquarium, molten lava, ...)?

Thank you very much for your cooperation. :wink:

-- alec
 
well, the easiest way to do it is to create the engine as standalone that accepts inputs from API to control each "entity"

and then create a seperate process for each "entity" and channel the keyboard/mouse/controller inputs to go through the main actor, and then allow NPC/environment threads that run with their AI that feeds their "control data" through the API into the main game thread.

that is pretty much the only way i can see the future of gaming to go that will support multiple cores and processes ( not just sub-threads inside the main thread ).
 
alec said:
Here goes:
Is it right to assume that in a game like Fallout, there is a program controlling the world (the environment) and a different one controlling the character(s), each with their own logic, parameters, code, ...?
Click to expand...

It's quite hard to tell since there are many ways a game could've been designed and coded to achieve the same result. What you're describing sounds like OOP(Object Oriented Programming). OOP is a double edged sword, on one hand, it simplifies a lot the design, thinking of everything as "objects" that have methods of their own.

But on the bad side, depending on how much OOP you choose to "use", the program can turn into an unmanageable and unflexible mess. For example, you could just have a list of independent characters, a map object, and let them handle everything on their own.

Some other people choose to go more "object oriented" and start adding other methods like everything being based on a same "object" or being part of a "world" object that handles and processes everything for them. And it could go on and on, leading to overengineering.

If so, is this the case for all games (3D as well)?
Click to expand...
As said before, it depends on what's the base design of the code, so it's not easy at all to tell. In the end, what matters is that it's as flexible as possible to extend later. Or others would do horrors just to meet a deadline.


Do small, animated objects also have their own code/program (e.g. a pit of fire, an aquarium, molten lava, ...)?
Click to expand...
It's quite common these days that separate objects that should be implemented based on the game are normally scripted(so there's no need to recompile it each time an object is added, or even test it at runtime), or that the format allows as much as they need.


Of course, all this might seem a bit hard to understand at first, so I guess the best way to know is to check it out for yourself! Try coding and see what designs you can come up with at first. There's no set design on which a game should be built, but there are some common agreements on the most efficient ones.
:)
 
Yes and no. Not that there is a separate "program" but there are many "moving parts". Specific libraries/objects/processes that are designed to handle specific tasks and accept or hand off data to other parts of the greater whole that need that information to perform their function.
 
It would be good to know more about the background of your queston, to answer it in the best way possible

That is, are you requiring help because you are going at it yourself, or is it just a question as an outsider looking in ?

A program is usually subdivided in many functionalities, hierarchically organized as to produce the game experience. You could call them subprograms.

To continue on your example of an animated object, you generally have pieces of code involved with rendering the 3D objects themselve, another controlling their animation (-> modification of their shape over time).
Such 'programs' exists as standalone libraries : Ogre3D is a rendering engine : with a little work, you can easily show a cube, or a 3D model you designed yourself, on screen.

Generally, the game logic, as explained by Dario, is pushed *out* of the game core to be defined in scripts. There you will generally consider the interactive parts of your game as objects : a character, a chest, a door. The modifications you will do on these will influence the lower parts of the engine (3D, animations, effects).
 
dario, everything in OOP is technically a type of object

or a sub-class of a sub-class etc which is an object.

go up the parent-child tree high enough and it will reach object type.

first you start off with the "main" thread ( which in most programs is actually signified by main ) and that calls all the sub-methods.

every method is a part of a class, and every class gets called by the main thread, and everything inside the main class is an object.

some designers/developers prefer lots of stuff being handled inside the main class, and others prefer the fewest entries inside it and favor a really small main class with very fast and tree-form classes.
 
alec said:
Here goes:

Is it right to assume that in a game like Fallout, there is a program controlling the world (the environment) and a different one controlling the character(s), each with their own logic, parameters, code, ...?

If so, is this the case for all games (3D as well)?

Do small, animated objects also have their own code/program (e.g. a pit of fire, an aquarium, molten lava, ...)?

Thank you very much for your cooperation. :wink:

-- alec
Click to expand...

There are pieces of code responsible for everything that happens, such as animations and calculations and loading and menues and inventory and movement and dialogue parsing...

These pieces are designed to be called at will and don't hog CPU time. The game loop calls them:

handle people's behavior (walking, shooting)
animate people (manage their frame and/or state switching)
draw city
draw interface
etc etc

... repeat above, until game is over.
 
Coding sounds SO far out bizarre to me... I have trouble coding a functioning website, and that's using graphic interfaces like Dreamweaver...

To see someone just stick together a bunch of code to make the computer do something is borderline magic to me.
 
Arr0nax said:
It would be good to know more about the background of your queston, to answer it in the best way possible

That is, are you requiring help because you are going at it yourself, or is it just a question as an outsider looking in ?
Click to expand...

I'm not into coding, it's just an outsider showing interest.

I ask because of something completely "unrelated": GUT theory.

I'm wondering whether a simulation of reality (like a game) consists of one big program (where the parameters are 'identical' for all the different elements), rather than a collection of programs that have their own logic and that do not really mix, but just work well together.

Yeah, I said this question is stupid.
 
It's not that dumb of a question. It's quite related to the problems computer programming is facing these days.

That is, on the hardware side, it's been a few years we have reached a 'limit' in pure speed (you may have noticed processors don't go up in GhZ anymore).
The innovation now rely on 'parallelization'. That is, if one core has a fixed limit in speed, the only way to make progress is multiplying the cores and making them work together, in parallel.

The problem in programming, now, is about using these multiple cores. Having one big undivisible program does not really play well with having multiple processing units.
Processing power will be wasted, and the game slower than it could be.
That's why game programming these days focus on making exactly what you said : a collection of programs that communicate together but work individually on specific tasks.

So, if you were about simulating reality in the best way possible, considering the power requirement, it would probably go this way : heavily parallelized.
 
which unfortunately game developers are not making full use out of.

have any game developers even started making 64 bit games yet?

none that i have seen
 
You must log in or register to reply here.
Back
Top