Agree.

I have spent time on frameworks, which is about the same thing as an engine. I've spent I don't know how much time making OO wrappers for SDL.

This is why I now prefer environments like Flash and C#. When I redid cowhead, I was able to get menuing, a status bar, a magically resizing and automatically scrolling gameplay area FROM THE PLATFORM WITH NO PROGRAMMING EFFORT. I was then able to simply work on the game code itself, and use designer type tools for making menus and buttons and stuff.

In flash, I admit that I did make a button class. Once. I then reused it in all of my applications since then. Yes, flash had a button thing already existing, and so I didn't need to do this. But I *DIDN'T* completely make my own framework/wrapper/engine from the ground up. Everything was based on MovieClips, which meant no rendering code AT ALL.

I agree that if all you want to do is make a game, go with a preexisting engine.

That said, I like making an engine. Sure, it won't be the most cutting edge or highly optimized, but it's one hell of a learning experience. Maybe I just fall more on the "engine programmer" side rather than "game programmer".

I guess my point would be: building an engine to make a game, bad. Building an engine as a learning experience, good (if you're interested in that kind of stuff).

Well, if you've never attempted an engine and don't know what an engine does, then how are you supposed to understand it? Of course you could get by with knowing how to use it, but when it turns out extra tweaking is necessary, you'll be paying up for your lack of architectural understanding (unless you got yourself a very good support agreement).

I guess it does depend on the kind of game you're making. If you're working on a next-gen all-platform FPS, I agree you're wasting your time not using one of the excellent engines available. But if your game needs a substantial amount of customization, regarding gameplay and/or art direction, an off-the-selve engine can impose limitations on your creativity. At least I have already played too much games that had an overly generic feel to them, while the potential for something much better was definitely there. Of course this doesn't depend solely on your engine, but being limited by it obviously doesn't help much.

Just my 2 non-game-industry-initiate cents though [smile]

Quote:Original post by remigius
Well, if you've never attempted an engine and don't know what an engine does, then how are you supposed to understand it? Of course you could get by with knowing how to use it, but when it turns out extra tweaking is necessary, you'll be paying up for your lack of architectural understanding (unless you got yourself a very good support agreement).

The "you must write something to understand it" argument is bogus. People write code in C++ without having ever written a compiler. People write OpenGL code without ever having written a 3D API.

While attempting to write something *might* give you a better understanding of how similar things work, it might not. And it certainly won't give you enough knowledge to offset your investment in time. Spending your time familiarizing yourself with the engine (or the compiler or 3D API) is a better investment than trying to build something similar in the hopes that the thing you build will be similar enough to what'll actually be deployed that it'll help your productivity.

Think about it. If somebody told you that they were ramping up a Torque-based project that would be starting in three months, would your time be better invested in learning Torque or in writing a Torque knockoff? While writing a knockoff might better help you grok the internals of Torque, learning how to use Torque will help you write a game.

It's all about the situation. I would easily say that if someone was highly motivated to create an engine and was just in high school, go for it. If a person is about to graduate college, within a year, I'd easily say grab an engine and build a game for your portfolio.

If you have time to dedicate and you really want to develop an engine, why not? Waste of time? I would argue against that. Not only does it teach you core mechanics and understanding of the functionality of game technology, you understand the thing from ground zero. I don't see how this is a bad thing.

Programming is programming and the key thing to take away from the experiences you have is upping your problem solving skills.

Can you really argue that a company will look at someone that built a great demo from an engine that he/she built by themself?

You sound like your talking in more of a game designers point of view than a programmers point of view.

True, if you're working towards a game, you indeed are better off familiarizing yourself with the engine you picked. Of course a lot of understanding can also be gained by inspecting the tool at hand, but without prior knowledge it should be pretty much impossible to select the proper tool in the first place. And that's where I think at some basic least experience with engine development is indispensable.

Don't get me wrong on this next statement, but I think the compiler comparisson is also a bit bogus. A compiler is a powerful and complex tool, but it's function is very straightforward, getting your instructions from high level language X to byte code or assembly. Despite all available options (and perhaps some resource packing), that's all it does. Still, I think everyone would agree your programming skill would be better if you have at least some understanding of the inner workings of a compiler. Engines by contrast have wildly different featuresets and the architecture draws much of its design from the underlying APIs, which in turn are based on the hardware capabilities. Somehow I don't think all this underlying theory is going to dawn on you while reading the engine manual.

Anyway, I realize I'm looking at your post the wrong way. If you just want to build a game and you come across an engine that does fit your needs, I agree that writing an engine yourself obviously makes as little sense as writing a compiler to implement a simple tool. I guess I'm just a stubborn programmer who takes too much joy from painstakingly writing stuff like this himself [wink]

Well, I wrote a basic graphics engine. Then trashed it. Then started writing it again in Direct3D. Then wrote a game demo with it. Now that I've finished the game demo, I'm trashing it.

The engine (both versions) took me a little over a year. I learned quite a lot, but now I'm kind of sick of it. I do want to be writing games, and for the moment, I'm sick of graphics, and to get my current engine to the stage that my previous one was (in functionality, even though the code was horrible) would take me a while since I'll be learning Direct3D along the way.

I'm a little sick of doing graphics stuff exclusively, so I've turned to Ogre. Hopefully, it will work out well and I'll be churning out a complete game in the next 4 months or so (just a puzzle game, not the hockey MMORPG that I've been designing for so long [grin]).

Anyway, writing a graphics engine, even one that you trash (especially one that you trash, if you know the reasons why you trashed it), will make you a better programmer.

Graphics engines can have a lot of interdependencies, especially engines written by beginners. Having to think around those dependencies, having to look all the way to the bottom of the barrel for a way around something, and then realising that you just have to screw design and write it in the most horrible, stupidly idiotic way possible just to make it work, makes you a better programmer. You learn the lesson that sometimes, you just have to make it work, and let a better design come later in a major rewrite/refactor.