• 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
JosephParrilla

Game Engine or not?

103 posts in this topic

Hey guys,

So Ive been reading about game engines lately, and Im kind of confused about them. My approach to programming has always been to use the least amount of abstraction libraries as possible without sacraficing too much time for complexity (I wouldnt do a game in x86 assembly :rolleyes: ) So what exactly does a typical game engine do for you?? Does it basically do common game tasks for you such as collision detection and AI? If so, how can someone learn how to truly program games by using one? Maybe I am thinking that they do way more for you than they really do.. I have been using C++/SDL lately and for me it is the perfect library because it gets rid of the really low level stuff, but allows me to really get into the code and learn about whate happening. There are no magic functions that solve problems for me.

So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine? I mean I know there are programs like Game Maker where pretty much anyone can make a game with, so where does the abstraction stop?? Where does a programmer put him/her self and say "this is the level I want to be developing my games at, this is how much help I want from the API"? I mean, if programs like Game Maker exist, whats stopping anyone from making some awesome game with almost no programming experience? Im really not familiar with these sort of programs but the wiki for Game Maker says it allows someone to make a game with no programming experience. If thats the case, there must be limitations on these sort of engines and prgrams right??
0

Share this post


Link to post
Share on other sites
GameMaker will get you so far but it is a general library. game engines are there to give a solid foundation to build your own game. There are many differences between the engines (cross platform, scripting, etc). Basically a game engine takes care of the fundamental (networking, inputs, etc) but you can build upon these or take them as they are. Major differences are some engines give you source code so you can get right into the code, others (like Unity) you get no source access so the scripting is the only control you have. If the scripting doesn't have access to an API that you need, tough.

There will be posts to this that will expand, or correct what I have said, but the general issue is that to build a game from nothing on your own will take a lot of time as there are so many elements for you to learn and develop. Game engines simply give you a base to use the core functionality or build from it.
0

Share this post


Link to post
Share on other sites
I looked at Unity, theres basically no true code at all.. only scripting like you said. There must be a downside to using a tool like this right?? I mean there are SO many kids who say "I wanna make an awesome MMORPG but I dont know programming". If things like this exist, what is the incentive for these kids to learn something so deep and complex as C++? I mean, I know I love programming in general, so using real languages and doing stuff from the bottom up is exciting for me. I enjoy learning whats happening on the lower level.

So your saying that these sort of engines and programs exist because doing it on your own from scratch takes too long... if thats the case why isnt every developer using these tools? I mean, if your goal is simply to make a cool game and possibly get others to play it, and you dont really care about whats going on in the code, where is the incentive to sweat through learning opengl and sdl when you could drag and drop some stuff and script and basically make a game equivalent to someone who wrote a million lines of C++ code to achieve the same thing? I just watched a video on youtube for unity3d, and in the second tutorial in a series, this guy has a full on jungle environment that looks awesome, something that would take alot of work coding from scratch.
0

Share this post


Link to post
Share on other sites
I wouldn't confuse programs like gamemaker with actual engines, engines can be considered as libraries which contain a frequently used set of functions so you don't have to worry about these yourself while working on a game project (this can be at a very low level, or at a very high level, depending on what the engine was designed for) while gamemaker is more of a toy providing a drag & drop interface for creating rather generic games
The philosophy behind engines is that it would be a waste of time to rewrite low-level stuff you already coded in a previous project when starting a new one, so why not bundle your reusable code together in a library?

About the amount of abstraction engines provide, you have to keep in mind that not all engines are the same, there's almost a direct relationship between the amount of abstraction an engine provides and its flexibility, a general-purpose engine could support a wide range of genres resulting in leaving a lot genre-specific implementations up to the client, while a genre-specific engine could provide all functions needed so the client doesn't have to worry about anything else than the game implementation itself

In the end, if you feel that you can maintain a good productivity by using SDL, then by all means keep on using it, you don't need an actual game engine to write games, nor should you worry about engines until you find yourself in a situation where you are doing more projects on a larger scale, when you reach that point it'll just be a matter of finding the right tool (since engines really just are tools) for the job, or rolling your own
0

Share this post


Link to post
Share on other sites
[quote name='joeparrilla' timestamp='1305296733' post='4810227']
My approach to programming has always been to use the least amount of abstraction libraries as possible without sacraficing too much time for complexity (I wouldnt do a game in x86 assembly :rolleyes: )
[/quote]

Game engines mostly aren't abstractions, and where they are they're implementing the abstractions that you'll need to do to be productive anyways.

[quote]
So what exactly does a typical game engine do for you?? Does it basically do common game tasks for you such as collision detection and AI? If so, how can someone learn how to truly program games by using one?
[/quote]

How can someone truly write games if they spend all their time reinventing the wheel?

[quote]
So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine?
[/quote]

No. Knowing what is happening is overrated.

[quote]
I mean I know there are programs like Game Maker where pretty much anyone can make a game with, so where does the abstraction stop?? Where does a programmer put him/her self and say "this is the level I want to be developing my games at, this is how much help I want from the API"?
[/quote]

A good programmer wants all the help they can get from APIs. The less code you write, the less time it takes, the less debugging you need to do, the less maintenance.

[quote]
I mean, if programs like Game Maker exist, whats stopping anyone from making some awesome game with almost no programming experience? Im really not familiar with these sort of programs but the wiki for Game Maker says it allows someone to make a game with no programming experience. If thats the case, there must be limitations on these sort of engines and prgrams right??
[/quote]

Absolutely. Programs like these can never satisfy every scenario/requirement. Or satisfy them better than alternatives. Same with APIs. Sometimes the abstractions prevent you from doing cool tricks that are required to get what you want. But the approach isn't 'learn cool tricks, then use the API', it's 'use the API until you can't do what you need to do easily'.
1

Share this post


Link to post
Share on other sites
A game engine takes care (or is supposed to) of those things that all games would need in order to work, a rendering system, a resource pipeline, input handling, network communications framework, sound system, graphic user interfaces, and so on, strictly speaking programming a game consist more or less on implementing the flow that defines when and how this things are used, rather than the functionality itself.

In this sense, programming a game presents its own sets of problems, challenges and tasks without even digging deep into the inner workings of the engine.

Its always good to know how the lower levels work, but usually programming an engine without having programmed a game first is like trying to make a wheel without knowing what you're gonna use it for, people carried stuff around long before they realized the wheel makes that easier, in this way, the problem must come before the solution.

1

Share this post


Link to post
Share on other sites
[color=#1C2837][size=2][color=#2B3730][size=2][b]Quote[/b][/size][/color]

[size=2][size=2]So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine?
[/size][/size]

"No. Knowing what is happening is overrated. "
[/size][/color]
[color=#1C2837][size=2]
[/size][/color]
[color=#1C2837][size=2]
[/size][/color]
[color=#1C2837][size=2]This is one of the most bizarre responses I have ever gotten lol. Is this a serious answer? Do you all actually think like this ? I would honestly hate using something and not knowing what the hell it was truly doing.[/size][/color]
0

Share this post


Link to post
[quote name='Telastyn' timestamp='1305298901' post='4810242']
[quote name='joeparrilla' timestamp='1305296733' post='4810227']
[quote]
So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine?
[/quote]

No. Knowing what is happening is overrated.
[/quote][/quote]


[color="#1C2837"][size="2"]
[color="#1C2837"][size="2"]This is one of the most bizarre responses I have ever gotten lol. Is this a serious answer? Do you all actually think like this ? I would honestly hate using something and not knowing what the hell it was truly doing.[/size][/color] [/size][/color]
[color="#1C2837"][size="2"][color="#1C2837"] [/color][/size][/color]
[color="#1C2837"][size="2"][color="#1C2837"][size="2"]So you would recommend that a new programmer whos never made games before to use the highest level engine possible to make a game, and not at all concern themselves with anything that they dont need to in order to finish the game?[/size][/color][/size][/color]
0

Share this post


Link to post
Share on other sites
A lot of it depends on your goal. Are you trying to learn or just trying to make a game?

If you want to learn, then going low level is what ya want to do. You want to learn the hows and whys of doing things. If you just want to make a game you can often ignore much of the lower level stuff and use libraries that can help you. XNA and others do much of the work and let you worry more about game play and the likes then about translations and buffers.
0

Share this post


Link to post
Share on other sites
Game engines provide libraries that give a solid (in most cases) set of code. It is probable that this is tested and therefore you don't have to worry about the possibility of bugs 9or that is the theory).

Scripting engines make it easy to get a game up and running using minimum effort. However you are stuck with thier code (unless you have source). People will use these engines because it gets them to where they want to go quickly. Others will build thier own engines as they want to have a clean pipeline that is built around thier needs (e.g. trying to get a FPS engine to make a RPG is not that efficient) and is efficient.

one example would be an artist who wants to get a demo up and running, they would use a game engine, 99% of the time it would be Unity.... What you have to remember is it is easy to spot a game by the engine used as the rendering is the same, in my opinion.
1

Share this post


Link to post
Share on other sites
[quote name='joeparrilla' timestamp='1305299475' post='4810246']
[color="#1c2837"][size="2"][color="#1c2837"][size="2"]This is one of the most bizarre responses I have ever gotten lol. Is this a serious answer? Do you all actually think like this ? I would honestly hate using something and not knowing what the hell it was truly doing.[/size][/color] [/size][/color]
[/quote]

After spending many years playing around with low level details and not getting anything actually done, yeah. Knowing the gist of how things work is good enough for pretty much everything. I don't particularly care about the mechanics of buffering and decoding video if I just want to play one. I want an API that reduces all that headache to 1-2 lines of code so I can go back to making the game.
[color="#1c2837"][size="2"] [/size][/color]
[quote]
[color="#1c2837"][size="2"][color="#1c2837"][size="2"]So you would recommend that a new programmer whos never made games before to use the highest level engine possible to make a game, and not at all concern themselves with anything that they dont need to in order to finish the game?[/size][/color][/size][/color]
[/quote]

[b]I recommend that a new programmer not make games. Learn to program first. [/b]

If your short term goal is to make a game, use the most/best APIs/tools to accomplish that goal.

If your short term goal is to learn to program, then some portion of that will involve mucking about in low level stuff to get used to debugging things there and get a better understanding about buffers, bit fiddling, pointers, implementing your own algorithms/data structures and the such. But all of that code should be throw away. It should be focused on gaining knowledge and experience, and once done a programmer should pretty much avoid doing any of it again.
2

Share this post


Link to post
Share on other sites
[quote]Can you explain how your microwave works? And if you can, does it make you any better at using it? How about the internal combustion engine? Forced air heating?[/quote]

As a programmer, it is your job to know how it works. I am not a microwave technician or car mechanic but if I was and came to fix your microwave or car wouldn't you want me to know how it works? That way if it is a problem out of the ordinary I would have a much better chance to fix it. Would you drive a car fixed by someone why it needs fixed, but not how? You would quickly find yourself becoming an unemployed programmer/mechanic/engineer if you only knew why but not how. Nobody would hire you. Try using that analogy you gave in an interview and see how it goes, I suspect not very far.
1

Share this post


Link to post
Share on other sites
[quote name='Burnt_Fyr' timestamp='1305301580' post='4810265']


Can you explain how your microwave works? And if you can, does it make you any better at using it? How about the internal combustion engine? Forced air heating?

Something I struggled with for a long time(and still do to some extent) is that 'why' is more important than 'how'.
[/quote]
Not really the best examples, because I know how all three work, and I have had to fix all of them. Without knowing how they work I could have never fixed them.

But I guess the same might be said libraries, if it works and does what you need it to, you don't really have to understand HOW it works. When it doesn't work or you need more, then you need to start working on the how.
0

Share this post


Link to post
Share on other sites
[quote name='TheTroll' timestamp='1305300795' post='4810257']
A lot of it depends on your goal. Are you trying to learn or just trying to make a game?

If you want to learn, then going low level is what ya want to do. You want to learn the hows and whys of doing things. If you just want to make a game you can often ignore much of the lower level stuff and use libraries that can help you. XNA and others do much of the work and let you worry more about game play and the likes then about translations and buffers.
[/quote]

Well Im a computer science major.. so naturally I just have a desire to know whats happening. After programming in assembly and C, I have a great appreciation for knowing whats happening underneath the abstraction. I dont plan to work in the game industry, I just want to do it independently and as a hobby. I just see so much talk about libraries like XNA and all that lately, I was under the impression that nobody does things with libraries like SDL and OpenGL anymore. I mean sure I want to make games, but I want to do it in a way that I learn whats happening and truly understand whats going on. Im not just concerned about "getting it done", I want to truly be knowledgeable and very good at it,


1

Share this post


Link to post
Share on other sites
[quote name='donkey breath' timestamp='1305301873' post='4810267']
[quote]Can you explain how your microwave works? And if you can, does it make you any better at using it? How about the internal combustion engine? Forced air heating?[/quote]

As a programmer, it is your job to know how it works. I am not a microwave technician or car mechanic but if I was and came to fix your microwave or car wouldn't you want me to know how it works? That way if it is a problem out of the ordinary I would have a much better chance to fix it. Would you drive a car fixed by someone why it needs fixed, but not how? You would quickly find yourself becoming an unemployed programmer/mechanic/engineer if you only knew why but not how. Nobody would hire you. Try using that analogy you gave in an interview and see how it goes, I suspect not very far.
[/quote]

Exactly.. Im a programmer. This is my life... why the hell would I just want to brush off the details? Im interested in this stuff, and seeing that it will be my career, I feel like I should really be an expert on it. saying that how stuff works doesn't matter just seems like a total cop out to me... Sure I dont know exactly how a microwave works, but Im not a microwave technician. I am a programmer though..
0

Share this post


Link to post
Share on other sites
[quote name='Telastyn' timestamp='1305298901' post='4810242']
[quote name='joeparrilla' timestamp='1305296733' post='4810227']
So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine?
[/quote]
No. Knowing what is happening is overrated.
[/quote]

Imagine this. What about an artist who just wants to paint, but he doesn't know anything about painting, techniques, perspective, colors, etc. Then he starts to grab some others artists drawings and start to copy them without even complaining HOW they did it. Will he ever archive his goal?.

Knowing the basics is not reinventing the wheel but if you know how and why a wheel was invented, you'll expand your horizon.

You wrote that because you already know what's happening in the low level.
0

Share this post


Link to post
Share on other sites
[quote name='Sunda' timestamp='1305304057' post='4810288']
[quote name='Telastyn' timestamp='1305298901' post='4810242']
[quote name='joeparrilla' timestamp='1305296733' post='4810227']
So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine?
[/quote]
No. Knowing what is happening is overrated.
[/quote]

Imagine this. What about an artist who just wants to paint, but he doesn't know anything about painting, techniques, perspective, colors, etc. Then he starts to grab some others artists drawings and start to copy them without even complaining HOW they did it. Will he ever archive his goal?.

Knowing the basics is not reinventing the wheel but if you know how and why a wheel was invented, you'll expand your horizon.

You wrote that because you already know what's happening in the low level.
[/quote]

Im glad that you and others are saying this. For second I thought just maybe I was crazy for having a desire to know how everything is working. I mean I guess I can understand if youre just a person who wants to make a game but isnt really concerned with being a true programmer you can sort of ignore a lot of things. But I cant imagine any programmer, especially the ones I know, who would brush off the low level details and not care to know whats going on. Most of the programmers I know are really into what they do, and are perfectionists... they want to understand the ins and outs of their craft.
1

Share this post


Link to post
Share on other sites
[quote name='joeparrilla' timestamp='1305304781' post='4810298']
[color="#1C2837"][size="2"]So your saying that these sort of engines and programs exist because doing it on your own from scratch takes too long... [b]if thats the case why isnt every developer using these tools?[/b] I mean, if your goal is simply to make a cool game and possibly get others to play it, and you dont really care about whats going on in the code, where is the incentive to sweat through learning opengl and sdl when you could drag and drop some stuff and script and basically make a game equivalent to someone who wrote a million lines of C++ code to achieve the same thing? I just watched a video on youtube for unity3d, and in the second tutorial in a series, this guy has a full on jungle environment that looks awesome, something that would take alot of work coding from scratch. [/size][/color]
[/quote]

There's a number of reasons I can think of, and most of them are biased toward my belief that we [i]should[/i] be using middleware for [i]most[/i] games:

- Because the business side often equates "owning our tech" with "owning our game". They think that for some reason if they don't build the whole thing from scratch, they are beholden to some other company. Save a few special cases, this is not actually the case. But I've had alot of trouble convincing "the suits" that paying $250k for an engine license is more valuable than putting that money (and then some) toward building an engine from scratch, debugging it, testing it, writing the tools, delaying development until it's finished... and in the end, most off-the-shelf engines have better tools anyway.

- Because programmers like to reinvent the wheel. They're often the type that say "well, I didn't create that wheel so I don't [i]really [/i]know how it works. Therefore I don't trust it and I will create a new wheel that does the same thing... only [i]my way"[/i]. I thought this way myself for many years. Then I learned that what I really want to do is understand [i]why[/i] the wheel works so I can make a better vehicle to use it. "Knowing what is happening is overrated" is a patently ridiculous response for a programmer, but "Knowing what is happening" is different than "Writing it myself". I find it equally ridiculous to go in and write the tech for a standard third-person shooter nowadays: between Unity, Unreal, Source, Torque, etc there is a solution at every price point.

- Because some programmers are fearful for their future employment. I hope nobody gets defensive about this answer: not [i]every[/i] programmer is this way. But some are. They're afraid that if development and scripting is so easy a designer can do it, that programmers become obsolete. This is also ridiculous: if designers/artists can do the [i]standard[/i] stuff, then programmers are free to do the [i]groundbreaking, awesome[/i] stuff. Instead they spend so much time rewriting the same damn pathfinding algorithm or rendering pipeline that they don't have time to really experiment.

- Because sometimes a game is so unique, it would be harder to write it with existing tools than to just roll your own. This is rare (I actually wish it were more common), but in my opinion it is the [i]only[/i] valid reason to not use middleware. Katamari Damacy, for example, needed to be able to do complex LoD and streaming not based on distance but instead based on the [i]size of the character[/i]. It needed to be optimized to display hundreds of low-fi models instead of a few hi-fi ones. The physics required a dynamically re-shaping ball. It was a game that they were better off writing their own engine for, or at least heavily modifying pre-existing tech.

In short, if you want a first-person shooter in a jungle environment, and you write it from scratch, I would argue that [i]you're not using the right tools[/i]. Middleware shouldn't be looked at as a way to replace programmers. It should be a way to empower them to innovate: a way to take away the drudgery of writing their 20th octree optimization and instead focus on coming up with new technologies that will make future games better.
1

Share this post


Link to post
Share on other sites
Ugh... "true programmer"... a phrase which rings of elitest BS to me.

There is no such thing as a 'true programmer'; you just get programmers who care about different levels of abstraction [b]based on their level of intrest.

[/b]Not every one who programs cares about even low level detail, they do what they want to get to their goals; someone who takes Unity and builds a game is no less a 'true programmer' than someone who decides to spend years trying to build one from the ground up. They both have different goals is all.

I agree that 'knowing what happens' is over rated. It [i]can[/i] be a useful skill to have but I wouldn't say it was a hard and fast requirement. For example a large chunk of the programming team on the project I was on at work have practically no idea how the graphics system works and a large chunk probably have no idea how to do graphics at all. Does that stop them doing their job? No. They trust that those of us who [b]need[/b] to know how these things work will do our job so they have the tools they want.

Take myself for example; my focus is graphics and high performance technologies which means I've spent alot of time figuring out how to optimally perform graphics tasks with the APIs, understanding how GPU hardware works, understanding how low level CPU hardware (cache, memory access, LHS, etc) affects runtime performance and how to program around it and, because it's a major feature of our work going forward, I have a very strong background in threading and task based systems. However, if I wanted to do say some networking I'd go dig out a library which is recommended by someone and not give a damn about what it does; if it works then I'm happy and that's all I care about. Same goes for audio coding; if I want audio in a game then I'll go and grab a library and be done with it, I don't care how it does what it does.

Frankly knowing [b]everything[/b] is impossible, or at least knowing it and being useful in it. Most of my advanced knowledge in the various subject matters comes because I've been doing these various things for about 15 years now in various ways.

However, when I started off do you know what I started with? BASIC. STOS BASIC on the Atari ST infact which was a game specific version of the programming language. At that time (mid-90s) it would be the same as using Unity now and I know a few people who made games in it and even released them commerically. The only reason I didn't was because I was more intrested in the lower level side of things but that was just my intrest and didn't make me any more of a 'true programmer'.

I think, also, you underestimate the volume of people out there using the various engines which have been released and not giving a damn about what goes on under the hood. Unity and UDK have A LOT of users and various games have been cranked out by various people using them.

So, if you want to make a game the best thing you can do right now is grab an existing bit of tech and get on with it.
If you want to write tech well the great thing is no one is stopping you but don't think for one minute that you are any sort of elevated programmer for it; chances are while you are solving some problems with your tinkering those making games are solving problems which are just as hard, if not more so, while making their games.
1

Share this post


Link to post
Share on other sites
[quote name='Sunda' timestamp='1305304057' post='4810288']
[quote name='Telastyn' timestamp='1305298901' post='4810242']
[quote name='joeparrilla' timestamp='1305296733' post='4810227']
So is the typical idea that someone should start out with something lower level like sdl and opengl, and once they know whats happening and they just need to be productive, move onto an engine?
[/quote]
No. Knowing what is happening is overrated.
[/quote]
Knowing the basics is not reinventing the wheel but if you know how and why a wheel was invented, you'll expand your horizon.
[/quote]

There's a difference between knowing how and why a wheel was invented (the gist of it) and developing your own wheel from scratch and going through all the testing/debugging there-in.

When you're building a car, it's useful to know what wheels are, what they do, how they fail. You don't need to get the in-depth knowledge that comes from building your own wheel. Your end goal (the car/your game) will be better if you use someone who's been making wheels for years than using some wheel you cobbled together.

[quote]
Imagine this. What about an artist who just wants to paint, but he doesn't know anything about painting, techniques, perspective, colors, etc. Then he starts to grab some others artists drawings and start to copy them without even complaining HOW they did it. Will he ever archive his goal?.
[/quote]

Your analogy misses the point.

An artist needs to know techniques, perspectives, color theory. Does knowing how to make paint, or brushes help an artist make art? Probably a little, but it's not absolutely vital to make great art. And it's something that is likely to be lost on a beginner. Those low level skills are not nearly as vital as the technique and experience actually trying to make art.

Likewise a gamedev (as opposed to an engine developer) doesn't really need to care about how game engines do a lot of things they do. Sure, it helps a little, but not nearly so much as knowing how to tie the different parts of a game together, implement the rules effectively, and the experience of actually making games.

[quote]
You wrote that because you already know what's happening in the low level.
[/quote]

Pssh. As if 'low level' was something that was uniform and applied to every piece of code. I don't have deep domain knowledge about every part of a game. How could I? It'd take years of research and practice. By the time I got to the end half of it would be obsolete. At some point you have to triage what you're going to do with your time. Getting the gist of something is usually the best bang for the buck time vs utility.
0

Share this post


Link to post
Share on other sites
Wow seems like I sparked a pretty interesting discussion, Id like to see what else everyone has to say. As a side note then, do you think that going the C++/SDL route is impractical at this time for making games? I mean put it this way, I dont want to use a drag and drop interface, I want to write code. It seemed like SDL made sense for me, is that what alot of others use? Or is the general consensus to just use whatever makes game programming as easy as possible?
1

Share this post


Link to post
Share on other sites
[quote name='donkey breath' timestamp='1305301873' post='4810267']
[quote]Can you explain how your microwave works? And if you can, does it make you any better at using it? How about the internal combustion engine? Forced air heating?[/quote]

As a programmer, it is your job to know how it works. I am not a microwave technician or car mechanic but if I was and came to fix your microwave or car wouldn't you want me to know how it works? That way if it is a problem out of the ordinary I would have a much better chance to fix it. Would you drive a car fixed by someone why it needs fixed, but not how? You would quickly find yourself becoming an unemployed programmer/mechanic/engineer if you only knew why but not how. Nobody would hire you. Try using that analogy you gave in an interview and see how it goes, I suspect not very far.
[/quote]

I don't think you are picking up what I'm laying down. If you drive a car, that you didn't build yourself, does that mean you can't drive it as well as the mechanics who did?

[quote name='The Troll']
Not really the best examples, because I know how all three work, and I have had to fix all of them. Without knowing how they work I could have never fixed them.

But I guess the same might be said libraries, if it works and does what you need it to, you don't really have to understand HOW it works. When it doesn't work or you need more, then you need to start working on the how.
[/quote]

That is the point I was trying to make.
0

Share this post


Link to post
Share on other sites
[quote name='joeparrilla' timestamp='1305314540' post='4810389']
Wow seems like I sparked a pretty interesting discussion, Id like to see what else everyone has to say. As a side note then, do you think that going the C++/SDL route is impractical at this time for making games? I mean put it this way, I dont want to use a drag and drop interface, I want to write code. It seemed like SDL made sense for me, is that what alot of others use? Or is the general consensus to just use whatever makes game programming as easy as possible?
[/quote]

full disclosure: I am one of those who likes to make wheels. I've got my own math lib, a d3d renderer, an audio library that works just like my mackie. Lots of demos, but nothing that I couldn't have done in ogre/cegui/fmod with about 1/100 the headache. I'm happy with the route I took, but am dismayed by the amount of time lost that I could have spent working on my games. IMO you will learn more faster by taking existing tech and running with it, then trying to build the mill to grind the flour to make the bread.

I've not used sdl myself, but it is often recommended by those that have.
0

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