So my main question is that why alot of you use API/libraries like directx/opengl/sfml/allegro/sdl/xna and etc to make games rather than use an engine like unity/udk/troque? Doest using an engine make game dev a lot more streamlined and easier than using an api? What are your reasons?
How come many of you prefer to make games from scratch rather than use an engine?
Marketplace Seller - Reputation: 8941
Posted 29 December 2012 - 07:25 PM
Depends on the size of the game, and the requirements.
I'm making a 2D tile-based RPG. SFML is just as good for that as Unity or UDK or Torque would be, since those three engines aren't geared towards the type of game I'm making.
Further, making it "from scratch" (building ontop of SFML which is built ontop Win32 and OpenGL, so not really from scratch at all) provides educational benefit as well.
Using an engine is really great. For most 2D games, however, building off of a 2D API like SDL/Allegro/XNA/SFML would probably be better.
Making your own (non-2D) engine, except for educational experience or just for fun, is probably counter-productive to the end-goal of completing a game.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Members - Reputation: 751
Posted 29 December 2012 - 07:59 PM
The reason people choose to roll their own, is often because they want complete control over what happens in the code, and/or to really learn about how stuff works at a low level, and/or to optimize at a low level.
If you always use engines, or even libraries, you won't learn the low level stuff that happens. A quick example is collision detection, its really easy to call a function to do it for you, but writing your own detection systems, for things like rotated boxes, circles, and ellipses will grant you invaluable experience and knowledge. Then you can think outside the box because you truly understand these things.
Edited by EddieV223, 29 December 2012 - 08:02 PM.
If this post was helpful and/or constructive please give rep.
SFML2.0 Nightly Download Link http://en.sfml-dev.org/forums/index.php?topic=9513.0
SFML2.0 Tutorials http://www.sfml-dev.org/tutorials/2.0/
Members - Reputation: 143
Posted 29 December 2012 - 08:29 PM
It really depends on what you like to do.
If you like to design a game and want a finished product, go ahead and use an engine.
In my case, what I really like is to code. When you code from scratch, from time to time, challenges appear that you were not expecting. It's an awesome feeling when you get over those problems (and you usually learn a lot).
Sure, the game might look like crap, but I don't really care as far as I had fun doing it and learned something in the process.
(Note: This might not apply if you are working in a professional environment )
Members - Reputation: 1564
Posted 29 December 2012 - 09:06 PM
I'm super angry that I have to use stuff like DirectX and FMOD. I'd prefer ASSUMING DIRECT CONTROL.
No, my reasoning is pretty much identical to JD557's.
There are ten kinds of people in this world: those who understand binary and those who don't.
Members - Reputation: 1028
Posted 29 December 2012 - 10:57 PM
I thought programming was a game!
. . . but seriously: I never use a game engine. Following is why.
Game engines get in the way of what I want to do more often than they save me work, and they consistently still somehow fail to do things I need them to do. "I don't care that there's a material for a bloom shader; I want the FBOs you used to do it!" When I want to try a new algorithm, or do something no one thought of before, I don't want to be trapped in the framework some programmer thought would be all I'd ever need. No one can anticipate what anyone else will eventually want to write, so modern game engines, invariably never playing gracefully with outside code, hurt me.
Game engines, particularly proprietary ones--though open-source too due to the nature of the number of people working on them--almost always aren't up to my specifications of intuition. I am a perfectionist, and by nature I constantly tweak things down to the point where I spend an afternoon rewriting something just because its design isn't completely bulletproof and intuitive. I like my APIs to be obvious to use, robust, and powerful.
First, there should be at most one built-in way to do something, and it should be the best way--not different ways for different cases, different ways depending on context, hidden ways, and so on. I don't need four different ways to do something simple. It should be obvious, just by guessing, what the API does, and there should be one way it does it, if it does it at all.
Similarly, there's a point where the benefits of abstraction are overwhelmed by the cost of understanding it. I don't want to have to read pages and pages of documentation just to do something simple. In the best projects, documentation serves as a clarification and shortcut guide for advanced users--not an indispensable prerequisite for newbies.
Second, any internal software development is an exercise in balancing abstraction with power. Game engines fall far too heavily in the former for me. I can never do things the most efficient (or even reasonably efficient) way.
On a related topic, game engines tend to be bloated and hard to understand. Take the Bullet Physics Engine (which is actually a library). It's great: it works well, it's fast, and it is the de facto standard for physics engines—open source and proprietary. It's also horrific to read. As a newcomer, try reverse engineering some of the examples. It's next to impossible to just jump right in and start using it. I know that Physics simulation is not easy, but 4 megs of source is only justified if it's easy to understand and easy to use. Bullet is neither.
Analogously, this is in fact one of the things I personally oppose in the software industry: Parkinson's Law of Data, and a general lack of concern for system resources. Modern games ship with gigabytes of data, much of it never used. Why? Part of it is just that games are getting better, but a lot of it is due to wasteful game engines and content production pipelines. True, it's very easy to add new assets, but you lose a lot of value when you need a custom IDE or content management system to make sense of it all.
Game engines are often expensive or impose licensing restrictions. The last thing I want is to write something and then find out that 10% of my income from it goes to the game engine, or that I have to release my code under the BSD Revised Unported Attribution Commercial Software License rev.238b or suffer the consequences. Libraries have the same issue, but less so.
Perhaps the best argument, though, is the joke I opened with: programming is a game, and I for one find it amusing to write more powerful software with less code. Someone else might need a $500 license to use a game engine, but I derive joy from writing something faster and more elegant from scratch, even if it means I have to remake some wheels.
As an important clarification to my above points, I remind you that game engines and libraries are distinct. While I never use game engines, I almost ALWAYS use libraries. I can't get around the cruft of things like OpenGL (and the greater cruft of Direct3D) without doing drastic things like writing drivers for every graphics card ever. Similarly, there's sense in using things like SDL, wx, or QT, because no one wants to write a cross-platform windowing toolkit/system (except those guys, apparently).
But, in keeping with the above points, I try to choose libraries that are small, fast, and extensible--and when that's not an option, I almost always end up using a very small subset of the function calls available. Finally, when all else fails, I write a pretty API that exposes all the power of a library with the cleanliness I expect--doing this is only possible with lower-level libraries, and in fact I do, it seems, gravitate toward those.
The largest library I use is the code that I personally have written over the years. My OpenGL library can do everything the graphics component of a professional 3D game engine can do (or can, with a bit of code; it's designed to be more like a series of foundation classes than a plug-and-play sort of game-making-algorithm), yet it's comparatively tiny.
I'll concede that my strategy of making better wheels where bad ones already exist doesn't work to churn out games. I've noticed that I find place(s) for at least minor improvement whenever I try to use any library, and I spend more time than I should improving the library instead of actually making the application based off it. But, maybe this just tells me that I'm more of a researcher than a developer. I don't know.
On the opposite spectrum, I recently successfully released a number of small Python/PyGame games by just rewriting everything from scratch each time, and refusing to use any base code. Naturally, this doesn't scale past small applications like that.
So personally, for me:
- Libraries that you occasionally call into are good, but only if they are well-designed. Otherwise, try not to use them, acknowledging however that sometimes using a bad library is a necessary evil.
- Avoid game engines like the plague.
Crossbones+ - Reputation: 1373
Posted 30 December 2012 - 12:31 AM
I enjoy coding. It's fun and a passion. I understand you still must code when using a game engine, however it's generally very high level and a lot more simple than code I would write when I'm developing without an engine.
Learning how to program using a Game Engine doesn't seem very good to me (Unless you're an artist). Many programmers I've seen who learned to code with an engine write painfully slow and pointless code. I learned how to use C++, and waited a year before jumping into Graphics. I'm still learning different quirks surrounding the language and exploring C++11, however the experience I gained from learning a language and not an API / Engine is helpful and an underlying reason why I enjoy programming. I understand peoples code, and it's an amazing feeling. Actually being a coder makes me feel accomplished, and every time I spend a few days working on a problem / fixing a problem, I get an amazing sense of accomplishment.
The community for many Game Engines reflects many of my points. On the Unity forums, far too many (Even the well respected) of the programmers learned with Unity, and as a result, are not as helpful had it been a low-level programmer who had joined one of the teams on the forums. They don't normally write efficient code, and don't understand what their code does besides what they know from Unity. This isn't helped by the fact that the forums are barraged with teenagers trying to recruit actual game developers for their new "Zombie-MMO-DayZ however Better-FPS". I'd say about half of the community is twelve year old's. I should link you to a post (Albeit old) from a group of twelve year old's who had promised their school they would make an MMO (bigger than World-Of-Warcraft) and were looking for a team to make the MMO for them.
I respect the developers on the Unity Asset Store however. They are some of the most hard-working programmers I've seen and they make amazing software. It's no wonder that many of them work as programmers at larger studios (I've seen some from the likes of Electronic-Arts) or use lower-level API's.
I believe using an Engine is smart if you understand how the Engine works. This is the main reason why I'm learning OpenGL. I want to understand. I constantly read about Security (Security+), New programming languages, design patterns, practices, Books on new languages (and current languages). Understanding is important to me. I felt a feeling of "This is all to big for me to understand" when I started. There's just so much, it's hard to sort through it all.
Wow, that was a rant ! Cheers !
If you need some photo editing done, contact me:
if you want some programming help, or are recruiting for a game development team, either PM me on here or email me up there !
Members - Reputation: 1302
Posted 30 December 2012 - 12:52 AM
couple of years ago , at the beginning of our current project we did experiment with Unity. At the beginning we were all happy, the artists were happy because they had their nice environment to work with shaders, illumination and what not, I was happy looking forward to a relaxing development year full with lots of vacations and no graphics programming involved.
After a couple of months, the pretty picture started to fall apart.. loading time went biblical (>60 seconds), shadow quality wasn't good enough and untweakable for our needs, the entire working pipeline was VERY different (I wouldn't say bad.. but way different) from what we were used to, motion blur was more like LSD-acid effect. Luckily I had a DX11 pet engine that I was working on for fun and one sunday, for fun I imported the track and car we were developing as example in, and got the thing loaded in 7 seconds with the shadows just as I needed... after a couple of meeting with the entire team, Unity was out of the window, and my holidays were canceled
I look forward to the day I will be able to pick up an engine and be able to use it for my work.. it is the proper, sane and smart thing to do. Sadly, for the moment, we're not there yet for the kind of projects I do. But, if I were to start a new project tomorrow, my first move would be to check out a 3rd party engine first and evaluate if that could be of any use.
Members - Reputation: 131
Posted 30 December 2012 - 02:08 AM
I use directx on top of win32 and that is because I just want to learn things. So I'm making my own engine atm. But if I would in the situation, that I just want to ship some "little" game for mobile or tablet to market, I think I would use an engine. Would save a lot of time.
Awhile ago I read a little column, that many of finnish game companies are using Unity at the moment because they can concentrate more on developing contents of the game rather than adjusting the engine. And they are choosing Unity because it's quite easy to use. I also used Unity engine when we made networking game project in our school and it's really easy to use. Quite many finnish game companies, which are perhaps start-up companies or beginning companies have some nice idea so they just want that idea as fast as possible to market. Developing an engine would cost money and they couldn't concentrate on the original idea hence they have to develope the engine for it. But that's not what everybody does, but it seems that majority though.
Members - Reputation: 1050
Members - Reputation: 314
Posted 30 December 2012 - 06:21 AM
I believe, there are as many valid reasons to not use an engine as there are to use one.
- Learning to use an engine takes time. Sometimes it's faster to do it yourself, especially for small projects and if you don't plan on doing another similar project.
- NIH syndrome and it's not always bad.
- Prevent vendor lock-in. What if the engine developer decides to stop supporting the engine? What if license terms do change? What can you do when there is a bug in the engine, will it get fixed or do you have to work around it?
- Cost, sometimes doing it from scratch is cheaper than licensing an engine. Sure there are free engines available but sometimes they don't offer what you need or have strange licenses (especially the "free" versions of commercial engines) or even unclear licensing conditions.
- If you do it yourself you can learn how it's done. If you're using an engine, you learn how to use an engine. (Often the first one is more fun, but also less productive.)
One more thing, maybe it get's a bit offtopic (just couldn't stop). I believe doing it yourself gives your product much more value. Not necessarily value in the sense that you will get rich. But you yourself will value it much more. Even if this only means that you will be more confident it might pay of. Maybe it makes you decide to sell your games for a few dollar/euro/... more. And to tell truth I would prefer to sell a few hundred games for 20 or 30 bucks than be one in a million developers that sell their crappy app for 99cent. Even if the 99cent developer get's more money out of his game. I can't imagine have worked on a game for month and the have people pay less than a few dollar for it. It must feel horrible to produce something that is of so little value to the customer.
Note: I've never published a game and don't work anymore in the field, it's just my personal opinion. And I feel this even more stronger ever since I work on commercial software. You basically have a good (not perfect) product that is of use too the customer and he's paying a good price for it. If it wasn't worth it price there wouldn't be any customers...
The great thing is that even though they aren't very many customers the company is having a quite string relationship with them. Of course they exspect that, since they are paying each year to receive maintenance.
But can you imagine a 99cent app developer having a strong connection to his clients. (With strong I don't mean a facebook page and a forum or similar things.)
Sure even if you sell your game for 60 dollar you won't have the same kind of connection to your customers as a software house that is selling licenses for a couple of thousand. But you can offer much more than someone that is putting it out for 99 cent.
This is all from a developer point of view. If you're an artist it's probably not as important because your work will show on the screen and can be valued.
But to connect everything, using an engine can sometimes feel a bit like seeing an artist using poser (that strange 3d software with predone characters or something, don't exaclty know). Even if he/she might get something beautiful on the screen (most of the time poser users don't) as soon as you hear it's done in poser you think "oh well... can't have been much work".
Same thing with the unreal engine, everybody knows what the engine can do. And everytime I see the logo when a game starts, I ask myself "What did the developers do?".
It feels a bit like Java, when I hear someone say he's written application X in Java. Well did he actually develop something? Or is he only the one that is collecting pieces from the standard library, like those paint by numbers picture. (Yes, I do hate Java.)
Crossbones+ - Reputation: 264
Posted 30 December 2012 - 10:15 AM
Question - What is SFML - First time seeing the acronym ?
I like coding myself, and I got into game programming because I got frustrated with others game engine where the AI (Artificial Intellegence) seemd to not provide me as a player with a way of winning.
By not using an Engine, I can ensure that my games are designed to "Play" the game with you as if I were sitting across the table from you. By incorporating a "Learning System Routine", I can even simulate you playing yourself, How is that for Stratedgy ?
Your Brain contains the Best Program Ever Written : Manage Your Data Wisely !!
Members - Reputation: 1007
Posted 30 December 2012 - 10:24 AM
Currently i try to use libraries if the task requires very specific code, for example platform specific things (loading files, windowing, input...) and lets say parsing a file format. Maybe even a math library with SIMD code for different platforms because that is platform specific too.
Members - Reputation: 301
Posted 30 December 2012 - 10:32 AM
SFML is quite nice I must say, and very easy to deveop with.
Check out my new blog: Morphexe
Marketplace Seller - Reputation: 8941
Posted 30 December 2012 - 11:13 AM
As Morphex mentioned, SFML is another library for getting a window for graphics onscreen, with input events, sound, and other features.
SFML, the name of the library, stands for "Simple [and] Fast Multimedia Layer". It's designed in C++, so it has a more OOP-ish design than other libraries like SDL (Simple Directmedia Layer), but that is not a plus (nor a negative), simply a fact about its nature. Honestly, for lower level libraries, too much OOP-ishness sometimes gets in my way.
SDL and SFML are both great, but my preference leans slightly to SFML. I've used them both for several years each. Neither is necessarily superior to the other, except in minor ways.
All glory be to the Man at the right hand... On David's throne the King will reign, and the Government will rest upon His shoulders. All the earth will see the salvation of God.
Members - Reputation: 518
Posted 30 December 2012 - 11:29 AM
Learning how to program using a Game Engine doesn't seem very good to me (Unless you're an artist). Many programmers I've seen who learned to code with an engine write painfully slow and pointless code. I learned how to use C++, and waited a year before jumping into Graphics.
This is a good point. These engines like unity etc. really do so much for you, it doesn't show you anything about how the pieces fit together to make the end product. If you become skilled at programming you can utilize libraries to help you out but from there on you are "in control". It is the difference between a chisel and a CNC router.
Stay gold, Pony Boy.
Members - Reputation: 423
Posted 30 December 2012 - 11:43 AM
I see engines as being of two types: hobby engines that were designed to be more like game-making 'kits', a stand-alone product whose developer's sole intention is to maximize profits by creating something that appeals to a greater audience of people that just want to make games (non-coders) without knowing anything... and on the other hand there are the high-end triple-A title engines like id Tech, Unreal Engine, etc.. which were not designed to be stand-alone game-making 'kits', but are the underlying software of "serious games".
The high-end commercial engines are typically not afraid to expose the developer to the complexity of its internals, whereas the hobby game making kit engines are designed with the sole purpose of making the tech itself transparent, whether it be by providing tools or an API, or simple scripting language.
The reason I pointed out "serious games" is because these game development companies strive to milk the hardware for every possible drop of performance they can, to push polycounts and shader operations to the max - because mainstream games are always trying to top themselves in terms of measurable quantities - like frames per second and polygons per scene. Nowadays they are just trying to make everything look realistic without making it feel good - because screenshots in a magazine or on the screen only convey that aspect in the advertising. Now they promote video games using videos of pre-rendered animations and (sometimes) zero in-game footage, which frustrates me the most. I want to see what *I'm going to see* when I play the game, not some dreamed up cinematic clip.
I was into making mods for Quake before the hobby game engines were a reality - there was one game kit I got my hands on when I was 11 called the GCS - or 'Game Creation System' by Pie In the Sky software (I'm sure they no longer exist).. It was a system for making wolfenstein 3D-esque DOS games, without programming (so awesome, as a kid).
The reality is that every piece of 3rd-party material you use to make something, be it a code function, a library, or a whole engine, is just a piece of *your* project that isn't really something *you* made. That means that *you* don't (generally) have the freedom to fine-tune it as you see-fit, nor do you have the ability to customize aspects of it that are outside your scope of understanding and/or ability. Some will recompile libraries to add in specific functionality, and even to optimize specific functions, but most ignore the possibility of these options all-together and take libraries as-is.
When you learn how to do things yourself, from the inside out, you get the power, control, and freedom to make as much of your project how you want it to be. Whether that be for aesthetic, functionality, design, or performance.. When you just use someone else's code, it will simplify and accelerate development, but it's a piece of *your* project that was created by someone else of possibly less-than-desirable skill and ability.
A lot of the times I don't want to be limited to the 'summed-up' options a library's offered functionality may entail, nor do I want to be concerned with my software being under the licensing requirements of some 3rd party code I could opt to use. I'd rather write my own code, that's suited specifically for my project's needs, so that I can maximize performance and resource consumption - CPU and memory/disk use.
It wasn't long ago I was using the Tiny C compiler for a project - and desiring to compile C code in which MSVCRT.DLL wasn't a dependency... some of you may enjoy that. I know it's possible - but it ended up being too much of a hassle for what I was trying to do. Microsoft's standard C library implementation will have to do, otherwise I may as well be writing my code in win32 assembly.
All-in-all, it's a trade-off between your project's desired delivery time, and your ability to control everything about your project, so that it can be exactly how you want or need, so that it can truly be *your* project. Most people with no experience whatsoever will choose the fast-delivery-time route, because it involves minor learning curves and immediate results.. I want it now so I need it now. I'm sure that just about every good programmer on the planet that's worth his salt didn't get started out by making a high-end game engine, or even a game-engine, they started with Hello World.
Crossbones+ - Reputation: 1332
Posted 30 December 2012 - 12:11 PM
I only ever write 2D games. If I ever write a 3D game, I will use a (free or permissively licensed) engine in a heartbeat.
For 2D, however, engines, or more appropriately "game frameworks" in 2D world, aren't really worth it to me with one exception which i will discuss below. A 2D game framework on top of DirectX or OpenGL is just not that hard a thing to write yourself and doing so is very rewarding. Further, 3rd party game frameworks tend to be bloated due to the constraint placed upon them that they must try to handle the requirements of any 2d game imaginable. When you roll-your-own 2D game and have the whole thing sitting on top of just a graphics, audio and input abstraction layer, you can make the "game framework" portion of your game extremely lightweight (e.g. I don't need classes for parallax scrolling to write a tetris-style puzzle game) and when you start a new game you can take that code and extend it as needed or not extend it at all.
The exception I mentioned above is when there is a requirement for crossplatform-ness as in the case of developing for mobile devices and supporting both iOS and Android without rewriting your entire codebase. In this case -- especially when iOS is involved -- I do recommend using a 2D game framework. Writing your own cross-platform layer and getting it right is not an easy thing. But here, too, for me at least, the fact that I end up using a full game engine in this case rather than a lower-level hardware abstraction layer is really just an artifact of what is available for free (i.e. cocos2d-x) rather than what I would actually choose all things being equal.
Edited by jwezorek, 30 December 2012 - 03:38 PM.