Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

133 Neutral

About koSar.

  • Rank

Personal Information

  • Interests
  1.   To answer your question: I'm currently working on a project with a mechanical engineering background. Its goal is to develop an offline-programming environment for an industrial robot with a game engine. I'm searching for definitions as I need to cover some theory in the project report as I can not assume that every reader (mechanical engineer) is familiar with what a game engine is or what a rendering engine does. I - myself - like it when there's a high-level definition of terms I'm not familiar with instead of being confronted with them in a report without any explanation. I hope this clears things up and doesn't let me sound like a total nitpicker... ^_^   @Juliean & Alberth: THX!   BR koS.
  2. Thanks for your input, HappyCoder and Alberth.   So, what I understand is, that "rendering" and "drawing" are used interchangeably, both in 2D- and 3D-context. Right?   I'm actually looking for a "high-level" definition for real-time 2D-rendering and 3D-rendering. What do you think about the following definitions?   real-time 3D-rendering: process of generating a 2D-image from a 3D-model (or various 3D-models making up a 3D-scene) in consideration of viewpoint, lighting, texture, etc. and drawing it directly to the screen.    real-time 2D-rendering: process of drawing a 2D-image directly to screen (blitting) or generating a 2D-image from various 2D-images in consideration of the layers that make up a 2D-scene (ie. background, center, foreground) and drawing it directly to the screen.   I'm looking forward to your feedback.   BR koS.
  3. Hi guys,   my question might sound stupid and maybe there's no clear answer for it but I'd really like your opinion about it...  ^_^   I'm doing some research about rendering currently and I stumbled about the terms "2D rendering (engines)" and "2D sprite rendering" quite a few times. My understanding was that "rendering" was the process of creating a 2D-image from the current state of a 3D-model (or various 3D-models making up a 3D-scene) in consideration of a viewpoint, lighting, texture, etc. and if the process is meant to happen in real-time, this image is directly drawn to the screen. Now, if I have 2D-data (sprites, bitmaps or however you want to call it...) that makes up a 2D-scene or a GUI-system there's no need for "rendering" in my opinion. All that needs to be done with this data is to draw it on the screen. Is it common to use "rendering" interchangeably to "drawing" in 2D-context or what does it mean in this context?   BR koS.
  4.     "...a framework comprised of a collection of different tools, utilities, and interfaces that hide the low-level details of the various tasks that make up a video game." (Sherrod 2007) "...collection of modules of simulation code that do not directly specify the game’s behaviour (game logic) or game’s environment (level data)." (Lewis and Jacobson 2002) "Arguably a data-driven architecture is what differentiates a game engine from a piece of software that is a game but not an engine. [...] We should probably reserve the term “game engine” for software that is extensible and can be used as the foundation for many different games without major modification." (Gregory 2015)   ...just to name a few definitions I found. :)
  5. Well, I actually did a lot of literature research but there are not many books or scientific papers that cover the entire history of game development and those who do it don't focus topics like reuse or game engines. I could name you a few sources that state that there was little to no reuse and developers didn't even aim for reusability before the 90s. At least the last statement didn't make it to my text as it felt too wrong for me. ;)   I thought I could point out when the first reusable game engine was established and how game development changed with reusable game engines but this seems to be quite impossible - especially if you have to do it in about 5-10 lines of text. I'll think about another "opener" for my text as I don't want to write something that's oversimplified and factually wrong.   But another question: How comes, that Space Rogue / Ultima Underworld or DOOM are often said to be the first games that based on a reusable game engine? Was one of those maybe the first licensed engine or the first 3D game engine?   I'd like to thank all of you guys for your input so far... ;)   Best regards koS.
  6. @Kylotan I actually got this from "Game Architecture and Design" from Rollings and Morris. They write about the 80s  "There were no good C compilers then, and the few that did spring up did not produce code small and tight enough to be usable for games. This meant that porting a game to another platform required a complete rewrite." and later on "Doom heralded the beginning of the C era of game programming. Watcom, the makers of the C/C++ compiler used to write Doom, must have experienced a huge boost in sales...". So I thought it would be ok to write "no compilers". :/   @Josh I understand your opinion but I can't rely on any experience in the game industry of the 90s and so I have to trust books and acknowledge the information I get from experienced people like you guys. :) I'll write that the term "game engine" arose in game development and became popular in the 1990s then. As both of you don't like the "assembly only"-statement I'll try to relativate this a little. You actually don't like the whole second paragraph, though... :) I don't say that nothing of the game-specific conglomerate was reusable but that it required further efford to get reusable parts from it. About the "monolithic architecture"- and "highly interdependent"-parts: I think it was Gregory in "Game Engine Architecture" who wrote that DOOM was the first games that made a clear separation between engine-specific code (rendering, etc.), game-specific code (game logic) and art assets. So it should have been one of the first games who had a component-based or modular software-architecture and most of the earlier games had a monolithic-structure for my understanding... :/   @lawnjelly Thanks for your comprehensive and interesting input. I actually wanted this text to be short...some kind of "opener" but by all feedback I got from you guys I start thinking that "digging in the history of game engine" (:D) is a dangerous endeavor that can't be handled within two paragraphs. Maybe I would be better off taking DOOM-engine as an example and go on to "modern game engines"... ;)    Best regards koS.
  7.   For my understanding "using a game engine" is a major kind of reusing code, i.e. by using the physics-system of a game engine you reuse the code you or some other wise fellas wrote in advance. :) 
  8. Wow, nice discussion and a lot for me to learn... :)   I tried to mix up some of your input with stuff I've got from literature and would be happy if you could give me some feedback on the result...(as you might have noticed: english is not my native language, but I hope it's readable) :P     Best regards koS.
  9. Hi everybody,   I would really appreciate if someone would help to unscramble my thoughts... :)   I'm trying to write a short summary about how "game programming" was when there were no reusable game engines. Let's assume (and I know it's controversial) that the DOOM engine was the first reusable game engine - so how where games programmed / build before 1993? When you ask google you'll get "games were written as singular entities from scratch in assembly" about 5.000 times but I don't know what to think about this phrase. Another thing I found was "games were monolithic software systems"...I like this a little more as it fits nicely with the reusable game engine as part of a "modular / component-based game architecture".   What do you guys think about that? If you could name some books (i've already read a few) that cover this topic - please let me know.   Best regards koS
  10. Thanks, 0r0d. I think my confusion is pretty much gone because of you guys. I'm pretty new to the topic and more in to pragmatic than theoretic stuff. But when I recently sat there and started asking myself about the more runtime'ish and tool'ish parts of the Unity-editor I got pretty confused...  :wink:
  11. I actually borrowed "required" from some scientific paper I read but I'm with you!  :)   I now wrote "contains components / subsystems for realization of non-gamespecific tasks (abstraction of hardware and generic, gamerelated tasks) during game-runtime" as definition for "runtime-component of a game-engine" into my imaginary diary. It feels like a definition that's to broad and vague to be wrong... :rolleyes:
  12. Two creative attempts for you guys to judge... ;) 1. ) "The runtime component of a game engine consists of components / subsystems which are required while a game is executed but do not determine a game's specifics." 2. ) "The runtime component of a game engine assembles all non-gamespecific components / subsystems required while a game is executed."
  13. First of all: Thank you very much for your answer! :)     Here you actually mean "game engine", don't you? He makes the destinction (even if he says it's often blurry) between "runtime component" and "game" where "game-specific subsystems" come into play. Latter are (for my understanding) what you mean with "data made using tools" (ie. models, textures, audio and scripts for player-mechanics, -health, AI, ...). So by "understanding how to use the data made with tools" the "runtime component" of the game engine makes a game executable may the game-specific stuff be whatever (that's what I meant with "independent from game-specifc stuff"). Better? :/
  14. Hi everybody,   I'm currently reading a lot of stuff about game engines and game engine architecture. Jason Gregory's book "Game Engine Architecture" is one of my prefered sources and I guess a few of you might have peeked in it too. Gregory states that a game engine generally consists of two parts: a tool suite and a runtime component. The term "runtime component" leaves me puzzled. How would you define what the runtime component of a game engine is? My current understanding ist, that the runtime component makes a game executable (within development and by the enduser) independent from game-specific stuff (assets, rules). Is this completely wrong? I would appreciate if you would share your opinion... :)   Best regards koS
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!