Is game development "really" hard?
Pages: 12
Like so many say it is, but then say it isn't.
I find that writing the code when you know what you're doing is easy, almost too easy in some mental sense, but putting everything together to make a game a "game" is what seems like running into a wall to me.
Like understanding the concepts of what, how to and why for every little thing can be under your nerves.
ALTHOUGH SOME people really do a bad job of explaining what things do and what they're necessary for, I believe that a lot of failed programmers are simply for the most part failing because they aren't given enough details or insight into "what" they are exactly doing.
Too much "Do this." and "Do that." instead of "This is WHY you should do it this way, and this is what it does." most tell you "Just do it this way, end of story."
Anyways, I don't believe it's hard it's just hard to understand how to put every piece together without some deep help of every concept and helping someone mentally "see" how it would work and all flow together right.
But from any who can program games, anything to add? I can't really do much, a little SDL work, that's all. Trying to get animation down as a next goal.
Also, to add, I don't use Object-Oriented-Programming. Sorry! It's my choice.
I find that writing the code when you know what you're doing is easy, almost too easy in some mental sense, but putting everything together to make a game a "game" is what seems like running into a wall to me.
Like understanding the concepts of what, how to and why for every little thing can be under your nerves.
ALTHOUGH SOME people really do a bad job of explaining what things do and what they're necessary for, I believe that a lot of failed programmers are simply for the most part failing because they aren't given enough details or insight into "what" they are exactly doing.
Too much "Do this." and "Do that." instead of "This is WHY you should do it this way, and this is what it does." most tell you "Just do it this way, end of story."
Anyways, I don't believe it's hard it's just hard to understand how to put every piece together without some deep help of every concept and helping someone mentally "see" how it would work and all flow together right.
But from any who can program games, anything to add? I can't really do much, a little SDL work, that's all. Trying to get animation down as a next goal.
Also, to add, I don't use Object-Oriented-Programming. Sorry! It's my choice.
This question is a little too broad and open ended to give any sort of meaningful answer.
The difficultly involved depends entirely on what kind of game you want to make. A simple game like a vertical shooter isn't that hard at all. Just move a ship around, have it fire some bullets, and have bad guys come down.
On the other hand, something like Portal would be pretty difficult.
The difficultly involved depends entirely on what kind of game you want to make. A simple game like a vertical shooter isn't that hard at all. Just move a ship around, have it fire some bullets, and have bad guys come down.
On the other hand, something like Portal would be pretty difficult.
| Is game development "really" hard? |
Yes. Your best bet is to use an advanced engine such as Delta3D, and working in a team, with people having skills complementary to yours.
SDL and etc. will make you happy until they blow up in your face and make you realize the problem is not yours to fix.
| SDL and etc. will make you happy until they blow up in your face and make you realize the problem is not yours to fix. |
That's a horrible way to look at things. If you have that attitude, then any library is suspect and shouldn't be used, even Delta3D, OpenGL, DirectX --- hell even the STL.
Nonsense.
| then any library is suspect and shouldn't be used |
That's not what I meant to say, and it's definitely not what I did say!
I only advised for general caution.
Some libraries are of better quality than others; now please don't tell me you want to get into that discussion.
| Spoon Licker wrote: |
|---|
| I don't use Object-Oriented-Programming |
But OOP applies to games so well! OOP is based around the concept of having everything as an object, and everything in a game IS an object. If there's anything you should use OOP for, it's game development.
argggghhh I hate that people call a game library a engine. Also the prospective of hard is all relative. this means that its based on the person that is experiencing it. and of course nothing is hard when you know how to do it, but what might seen as difficult is getting to the knowing part. If your a person that can understand things completly with just logical then that is a asset and will aid you, but not everyone is like that this could also cause difficulty. Even the fact that there is a lottttt that must be coding especially for your first game or application that it is seen as tedious and some people consider the tediousness of it as difficult or they see the fact that a game is comprised of several didn't aspects, (without the use of a game library)
Mathematics
Physics
Computer artist ability( to note someone can be great at computer art but are horrible at hand art.)
Problem solving
The list can still keep going but hopefully you get the point a game many things all wrap into one nice little bow and if one part of the that game is not working properly it can ruin the whole thing.
Mathematics
Physics
Computer artist ability( to note someone can be great at computer art but are horrible at hand art.)
Problem solving
The list can still keep going but hopefully you get the point a game many things all wrap into one nice little bow and if one part of the that game is not working properly it can ruin the whole thing.
closed account (S6k9GNh0)
A game library is essentially a game engine. That's why they're sometimes used interchangeably.
It doesn't take a genius to make a decent game. Look at Minecraft and Notch...
Actually, my first game was pong in nothing but linear SDL, no wrapper, no abstraction, just plain ol' C and SDL. I'd say that's a good place to start out. If you attempt to overcomplicate things first, you end up not understand why its so complex and then you lose motivation which is a bad thing. Also, if you don't understand a concept, look on google first and if you can't find it, you can ask in a forum (as in not neccessarily here). I'm generally on IRC: irc.quakenet.org @ #cplusplusI especially knows how it feels to not understand something. Trust me, when I first started C++, I never would have thought I would become as understanding as I am now (although I'm always asking questions still >.>).
As for not using OOP paradigms, I don't see any real problem with that. Just when you feel the requirement to use a class, be sure it's a valid use of a class and don't be shy to use it. The only real advantage to keeping to functional-only programming is the fact that symbols become simple to manage (and some claim an advantage would be the avoidance of overusing OOP paradigms... which I would actually agree with).
It doesn't take a genius to make a decent game. Look at Minecraft and Notch...
Actually, my first game was pong in nothing but linear SDL, no wrapper, no abstraction, just plain ol' C and SDL. I'd say that's a good place to start out. If you attempt to overcomplicate things first, you end up not understand why its so complex and then you lose motivation which is a bad thing. Also, if you don't understand a concept, look on google first and if you can't find it, you can ask in a forum (as in not neccessarily here). I'm generally on IRC: irc.quakenet.org @ #cplusplusI especially knows how it feels to not understand something. Trust me, when I first started C++, I never would have thought I would become as understanding as I am now (although I'm always asking questions still >.>).
As for not using OOP paradigms, I don't see any real problem with that. Just when you feel the requirement to use a class, be sure it's a valid use of a class and don't be shy to use it. The only real advantage to keeping to functional-only programming is the fact that symbols become simple to manage (and some claim an advantage would be the avoidance of overusing OOP paradigms... which I would actually agree with).
Last edited on
I suspect game development is just as difficult as any other development. That is basically that as size increases, so does "difficulty".
D::: arggghhh not trying to rant or anything but anything called a game engine isn't a "engine" its a library.
No.... game library are not game engines...
A game library is just a directory of codes wrap into functions that simplify the process of creating games. a trueeee engine does nothingggg like that......
| A game library is essentially a game engine. That's why they're sometimes used interchangeably. |
No.... game library are not game engines...
A game library is just a directory of codes wrap into functions that simplify the process of creating games. a trueeee engine does nothingggg like that......
Actually, yes. That's exactly what a game engine does. More accurately, a game engine is a collection of interfaces and facilities that simplify game development by providing a layer of abstraction over common tasks, such as resource management and graphics rendering. Any possible distinction between engine and library is further blurred by the fact than many engines expose dynamic APIs for the purpose of extension.
I would consider SFML a game library (although it is strictly a multimedia library) in that it provides classes and methods to facilitate graphics rendering, network programming, audio streaming, etc. but I wouldn't call it a game engine because (1) it's not specific to games (it serves equally well for emulators and such) and (2) it gives you "too much freedom". IMO a game engine should have a standard format for models, textures, audio files and maps; it should be slightly more than just a "collection of interfaces and facilities that simplify game development"; the only difference between two games using the same engine should be the game's content - different story, characters, models, textures, etc., but everything would be virtually the same.
Last edited on
closed account (S6k9GNh0)
SFML isn't a game library. It's a multimedia library. It's just used for games a lot.
Last edited on
closed account (S6k9GNh0)
You said SFML is a game library but not a game engine.
</rofl>
</rofl>
Last edited on
| I wrote: |
|---|
| I would consider SFML a game library (although it is strictly a multimedia library) |
| I wrote: |
|---|
| but I wouldn't call it a game engine because (1) it's not specific to games (it serves equally well for emulators and such) |
I said it's a game library because it provides most of what you need to write a game; it's not a game engine for the reasons I posted.
| IMO a game engine should have a standard format for models, textures, audio files and maps; it should be slightly more than just a "collection of interfaces and facilities that simplify game development" |
For example, the graphics section:
Level - Provides
Hardware - Machine language
Driver - Vendor-specific interface
API (e.g. OpenGL, Direct3D) - Vendor-independent interface
Wrapper library (e.g. SDL, SFML) - Easier use of common calls
Game engine - Rendering of complex objects (models, maps, HUD, etc.) and special effects
SFML behaves as an engine in some aspects and as a library in others. It has the concept of sound file, which OpenAL doesn't have, but it doesn't have the concept of model, only of primitives. It has event handling but not scripting.
Last edited on
Consider something like the Source engine. All Source games use the same file formats, the same scripting language, everything; the only differences between them are in the actual game content. IMO that is what makes Source a game engine as opposed to a library. I would say it was a level of abstraction above what you define as an engine, which I would call a library.
Really we're just splitting hairs, but whatever.
Really we're just splitting hairs, but whatever.
We agree on what an engine is, but you seem to underestimate the broadness of my definition.
I didn't define an upper bound for the level of abstraction of an engine. Anything that provides at least enough abstraction to make common tasks (including among many other things reading common types of files and running scripts) in game development easier qualifies as an engine.
I didn't define an upper bound for the level of abstraction of an engine. Anything that provides at least enough abstraction to make common tasks (including among many other things reading common types of files and running scripts) in game development easier qualifies as an engine.
"Engine," is a loose term for the source engine ;) It crashes far too often, and the hit detection makes me sob.
I would define an engine as pretty much everything that isn't the game content. SFML is part of an engine, but not an engine in itself.
I would define an engine as pretty much everything that isn't the game content. SFML is part of an engine, but not an engine in itself.
Pages: 12