Hello Everyone..I am a complete beginner to Game Programming..I have a doubt..Does Unity and other game engines offer their own APIs like Graphics API etc?IAnd If yes,Are they easier compared to other APIs like OpenGL?Is that what helps us in reducing our work load?
Game Engine and APIs
Members - Reputation: 126
Posted 02 August 2014 - 11:46 AM
It is supposed to be portable and offers a much more easier API than low level Graphic APIs it uses beneath the surface. You could have easily Obtained this information by googling.
Yes other engines are similar, that's the whole point of engines to provide re-usable structured code invocations/usage. High level anything is believed to be more productive and reduce work load.
Members - Reputation: 132
Posted 03 August 2014 - 11:51 PM
I think you're confusing APIs with engines. To understand what an API is it's best to use an example. For example you have Microsoft Word, and you would like to make it read a new type of file or would like to export a file in a different format besides text, how can you do that if Word's source code is not available to you? You use an API that was released for that application by the maker of the application. The API basically lets you use parts of the code that could interact with the application. That's why it's called Application Programming Interface, it lets you literally interface with the application you are developing for. But you might think OpenGL is an API also, but there's no single application. It's an interace to the the graphics card driver, you can program the driver by using the functions revealed in the API. But an engine is more like an interface to a variety of APIs that handle physics, graphics, file reading, producing sound etc etc. So it's more like a program rather then a strict collection of function like an API.
Now to answer if it's easier then a pure API, yes and no. An API is more fundamental, that is you can say DrawPrimitive and specify a triangle to draw and it will draw it, or you can say PlaySound() and it will play a sound, so it's very fundamental and that's what makes APIs easy. The difficulty comes from organizing these very basic calls to create a whole game, as you can see it doesn't handle anything for you at all and you must program all the functionality yourself using these basic building blocks like legos. An engine on the other hand is harder because you have to do some setup that might be less intuitive, like creating scene managers, placing a sound and adding it to your scene before you can play it, creating a camera and attatching it to your player before you can even draw anything etc. You get the idea, you have to have a sense of the stucture of the engine to use it successfully. But it is easier once you get over that initial step because all the code for the most common game techniques is written for you already, you just have to do some setting up and calling some functions, to get it going, then you can concentrate on the logic of your game instead of worrying in which order you have to specify vertices in you model for it to draw correctly as in an API.
I hope that answers some of your questions.
You didn't come into this world. You came out of it, like a wave from the ocean. You are not a stranger here. -Alan Watts
Time flies like an arrow; fruit flies like a banana. - Old Wise Eastern tribesman saying
Members - Reputation: 1806
Posted 04 August 2014 - 06:48 AM
If the question is about Graphics APIs:
Unity does not offer a competing API to DirectX for Windows or OpenGL for pretty much everything else. Instead, Unity is built ON TOP of these already existing APIs. This means for you, the Unity developer, that you don't have to mess around with the Graphics APIs, Unity takes care of this.
You can still write Shaders and have Unity compile them for you, but only if you are not happy with the wealth of already existing shaders.
The first big advantage about Unity vs. using a Graphics API directly comes from not needing to know about Graphics API details. Depending on how light your use case is you might get results in Unity without any knowledge in 3D Graphics APIs or without knowing much about 3D Graphics at all.
The second big advantage is that you develop completly Graphics API agnostic in Unity. Its only when the Game gets built that the engine will either build a DX or GL version of it, depending on the Platform chosen (DX for Windows, GL for Mac/Linux for example). This way you can develop once without the need for porting (that is the theory anyway...)
If the question is about Unitys API in general:
Unity does offer some kind of API. It cannot be compared directly to a Graphics API, as Unity is a general purpose game engine that abstracts everything for the user, Graphics, Physics, and much more.
There is an expansive API Reference on the Unity page. The API In the case of unity are all the custom objects and methods you interface with in C# or Unityscript Scripts to program the behaviour of your gameobjects.
And yes, if you know the basics of programming, and the basics of 3D Graphics / Physics / whatever else Unity tackles, the API is easy enough to use.
if the question is "should I use X or Y":
This is a question only you can answer. I have not much expierience with developing directly with a Graphics API myself, but I guess its the usual trade - less control over the Graphics performance in Unity, less productivity if you have to write all the Graphics stuff with the API. You get away with less coding in Unity, but you have to stick with what the engine provides.
Thus you need to decide for yourself:
Do you need this much control over the graphics? Do you plan to build a game that will either bring PC hardware to its limits or has to run on very low powered mobile devices? Do you want to learn as much as you can about Graphics Programming?
-> write your own Graphics Engine with DX or GL.
Do you want to get a productivity boost? Do less of the coding yourself and rely more on the work of others? Get additional support in case of problems this way? Concentrate on other parts than graphics in your game?
-> Pick Unity.
Edited by Gian-Reto, 04 August 2014 - 06:52 AM.
Crossbones+ - Reputation: 3160
Posted 05 August 2014 - 09:32 AM
Think of an API as a lower level layer between the higher level languages such as is used to script a game and the machine/assembly language which you will never directly handle. An API by itself has a fraction of the coding libraries needed to make the usual video game. APIs connect the game source code to the hardware language under it which is shipped with every computing device. Type API into Wikipedia for a good concise explanation.
A game engine is much more, including libraries to support two or more languages used to develop a game (often high and low level languages), class file libraries ( or jar files ), input device libraries, physics libraries, GUI libraries, etc. So a game engine has potentially all the libraries in the game's main directory (of files and folders) and you manipulate those libraries and add both art and coding content by using the interfaces and editors which come with the game engine. Added to this inside the game engine are the possibility of other specific tools for use inside and/or outside the game, such as image manipulation software or a plug-in terrain editor ( plugging into the game engine ).
Keep in mind that sometimes only a fraction of the game engine or none of it is delivered with the game to the end-user - only enough to run and play the game. In this case the game developer uses the game engine to create stand-alone game coding from game source code. Smart phone games are at times like this, since space is limited in the phone. On the other extreme, a few games come shipped with the entire game engine so the players can also mod a game in many ways, such as PC games. Modders are common to big title games and scream for all the tools and the source code (part of whole source code). Also remember that some game engines are completely separate from the game source code while sometimes the game engine and the game are either partly or mostly integrated. Each has advantages and purposes aimed at delivering the smallest footprint of the game possible in the end-user's hard drive while satisfying the desire of the player.
Blender is the extreme in reverse. I really don't know what to call it, since it includes a game engine and many other things either related or unrelated to game development.
An API is an interface layer between the highest and the lowest coding, whereas a game engine is a collection of libraries for many purposes and manipulates or extends 2 or more layers of coding, usually high and low levels.
The largest game development companies working on huge game titles for consoles and PCs will have a game engine source code and also a game source code generated from it [by which they extend the coding to create consecutive versions of both the game engine and the game (Versions: 1.0, 1.1, 1.2,.........2.0, 2.1, 2.2, .......3.0, 3.1, 3.12, 3.2, etc.) ]. You can see by my post that each game dev company has a unique working philosophy in this business with all kinds of solutions to challenges. They all draw from a field of technical standards but implement them in different and unique combinations.
EDIT: By the way, we often see this stack of layers in game development....
Game Player/End User
Game Controllers and peripheral devices
Game source code
API ( such as OpenGL )
Hardware such as a PC
Edited by 3Ddreamer, 05 August 2014 - 09:37 AM.
Personal life and your private thoughts always effect your career. Research is the intellectual backbone of game development and the first order. Version Control is crucial for full management of applications and software. The better the workflow pipeline, then the greater the potential output for a quality game. Completing projects is the last but finest order.
by Clinton, 3Ddreamer