How is a game developed using a game engine?

Started by
8 comments, last by Drakkcon 17 years, 7 months ago
Hi, I would like to know what are the general steps in producing a game using a game engine like Orgre, Panda3D, Irrlicht or Torque. I have the impression that the developer uses the game editor to draw out the terrain, environments or the indoor scences and then he adds the game's objects. Then a scripting language which the engine supports is used for scripting. I have read the descriptions of the game engines on http://www.devmaster.net/engines/ and the engines has features like AI, collision detection, audio etc. How are these elements integrated into the game? Is it through clicking and selecting or do the developers have to script these features into the game? And currently, I am using the Unreal editor to create unreal game levels. I'm also studying unreal script. Is this also called "developing a game using an engine" ?
Advertisement
Hey there!

Well usually game generation is seperetad for
programming the engine and game content.
Since you are using a prebuilt engine all you need to the is create the content.

What's content. It can be lots of things but usually it is the art and levels.
But most engines today allows the integerate it all using some form
of a scripting language.
Basically look at the specificatiion of the engine you are using
see what kind of file formats they support create some basic content
and try to implement it using a scripting language or by using the engine itself.
Also for beggining most if not all open source engine have a good
community and a good set of tutorials and documentation to get you started.

Hope this helps.
Er... not quite sure what to say here.

Sometimes, in the case of AI, it can be scripted by designers or scripters, or it can be coded into the game as a part of the engine (this is the norm for games with advanced AI that needs to avoid using too much processing time on it).

To cut to the chase, when people say stuff like "developing a game using an engine" here, they usually mean coding the gameplay in something like C++, a compiled, relatively low level language, and possibly extending the underlying engine to allow for features they need and so on.

Though there are games that have 90% of their gameplay incorporated into scripts, this is mostly the norm for MMO(RPG) games.

Basically, the point is that the lower level you go with your programming, the more control you get. In an engine like Source (used for Half Life 2) for instance, it isn't even possible to script sequences into the game AFAIK, because the AI generates sequenses automatically. And even if it is, you couldn't make an MMORPG using the Source Engine for instance, because the network code is optimized for FPSs. You'd basically have to tear out all the networking code in the engine and start from scratch, or use a compatible, prebuilt network engine.
_______________________Afr0Games
Quote:Is this also called "developing a game using an engine" ?


Sort of. To be a "game" rather than a "mod" you probably need to turn the levels into a sequence, with its own UI and story. Ideally, you'd also do it as a total conversion, so that you don't use characters/weapons from the Unreal game. Then you could call it a "game built with the Unreal engine."

Note that the Unreal engine is pretty much top notch. Any cheaper alternative is going to have more limitations, and worse tools, in at least one (and possibly several) area/s. Much of the work of "building a game" in those cheaper environments go into working around those limitations (or building up capabilities that are not there).

Also, with Unreal, you get a certain default behavior of the character; as AI behavior is part of what a "game" is, you probably want to try to replace the AI behavior. You can do some things with UnrealScript, but to do it at the bottom layer, you really need the Unreal Engine license (which is expensive).
enum Bool { True, False, FileNotFound };
Game engines are not "game makers". It's rare that commercial strength game engines have a click and drag toolkit.

I've spent time with game production tools that ranged from a hastily-cobbled header file of common methods to a full-blown industrial-strength simulation engine with a GUI designer frontend.

It's hard to generalize because there are hundreds of engines out there, and the term "engine" is pretty loose. I really hate the games media for using it over and over again, especially since half of them couldn't tell BASIC from their lower intestine.

My personal game engine is a collection of useful C++ classes that I've had occasion to use at least once, and I base the game's components off of those classes using C++. I have collision detection methods, pathfinding, etc, that I call from my C++ code. I do not have a scripting language designed to create games using my engine, nor do I have a suite of tools for building maps and models.

Generally, developing a game using an engine indicates that you take other people's tools and then build your game using them. Those tools may be a loose collection of C++ classes, or they may be a full-blown content pipeline with native-code classes designed to use them (like Unreal).
Thanks for the replies :)

So, what is the difference between game scripting and using c++ to modify the game engine? Both of them are programming languages.

And game engines are not "game makers", so how do the developers create the nice scences which are shown o the game engines' website?

Lastly, the website in the first post describes the different capabilities of the engines like physics, lighting, AI, audio etc. How does the developer use these features for his game? Is it to use scripts to call them or to just use a "point and select" method?
'Scripting' is high level, C++ is low level. Don't expect to be able to use scripting for everything, although it is possible in some cases, where someone else has already done the low level work for you.

What do you mean by 'nice scenes'? Perhaps you mean the levels which you can move through; they are typically modelled either in a dedicated level editor, or in a 3D package like Max or Maya, or more typically a combination of the two.

Features such as AI, collision detection, and audio are not added via scripting and they are certainly not done with 'clicking and selecting'. (Very few things of importance are.) They are typically programmed in exactly the same way as everything else, usually in C++, and explicitly invoked at the appropriate points in the program's execution. They are also rarely totally standalone, and are tightly mixed in with the underlying engine. Once it is integrated at this low level, it may be possible to expose these systems to a scripting language, but this is not necessarily the norm.
About the "nice scences", yes they are the levels I'm referring to. I get it now.

And for scripting, in what areas of development are they used for?

And how are the physics,AI and other features of the engine incoorperated into the game?
Quote:Original post by Weng
And for scripting, in what areas of development are they used for?

Generally scripting is something the developer adds later -- I've only seem some professional level engines with their own scripting language.

Quote:And how are the physics,AI and other features of the engine incoorperated into the game?

Generally, you call these from C++ or whatever your main programming language is, alongside your game code.
Quote:
And for scripting, in what areas of development are they used for?


Scripting is a lot of fun, and something that I'm very interested in. Basically, scripting can be used for anything that you want to expose. In fact, it's possible to make an entire game using a scripting language.

Most of the time, scripting is used for AI, Game Data (Like weapons, missions, and things that are going to be tweaked a lot), and even the user interface (placing buttons, defining colors, etc.)

Popular scripting langauges used in games are Python, Lua, GameMonkey, and a few proprietary ones like Unreal Script.

Of course, scripting isn't necessary. It is possible to make a game totally hardcoded (that is, entirely in a compiled language). The reason this isn't as common is that it forces the developer to re-compile the entire game (that is, generate a new .exe file) every time they want to change something. This can take hours, so it's much faster to change part of a script which does not need to be compiled (although it can be).

This topic is closed to new replies.

Advertisement