• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
KrishKP

Game Engine and APIs

5 posts in this topic

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?

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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.

0

Share this post


Link to post
Share on other sites

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
0

Share this post


Link to post
Share on other sites

Hi,

 

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 coding

Game source code

Game engine

API ( such as OpenGL )

Machine/Assembly language

Hardware such as a PC

Edited by 3Ddreamer
1

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0