Many 2D engines provide as intuitive API as typical 3D engine does. In fact, 2D engines are not much different than 3D engines, given that 2D is just 3D with ortographic projection. Programming in 2D can be harder, however, if one's graphics API is poor, or if you are trying to create something innovative. But same can be said for 3D. Asset-wise, it's easier to make decent 3D than decent 2D, in my opinion.

Of course "changing camera view is easier in 3D", but that doesn't make 3D side "simpler" overall (if that's what we are trying to talk about here ) I still stick to my original points, and say that creating 3D artwork (and seeing it on screen IS more complex than 2D). The content pipeline. Making sure all those bones are okay. Scaling things to make sure they work fine. Checking uvmaps and everything... average Joe Programmer won't be able to do that. But... even average Joe CAN create 2D sprite and show it on screen. Thus, creating 2D art is simpler. End of story. Period. I rest my case. (lol) Agree on this. Depends how deep you go... I bet there's really complex stuff on the 2D side as well. And about quaternion... it's not necessarily needed much (and you can get aid). Overall I think 3D has some benefits... and much of the time it's "only one more angle" (although there can be pitfalls here and there). Engines are pretty good in this, you don't necessarily need to know too much (but I go agree that it's still bit more complex than in 2D) Yeh, but even the most skilled programmer needs to get those models from somewhere. --- Another bottom line is... that if you can get access to 3D resources AND can ensure that the content pipeline WORKS and that there's actually somebody pushing art from the other end, then 3D can provide many benefits over 2D. Changing camera views and many similar things are easy. But... if you are creating your first game then I think 2D is simpler and can get you faster results. In Diablo terms: 3D is like the Wizard, and 2D is like the Warrior. Warrior is powerful in the beginning and gains expertise fast, but in the end the Wizard (if you have the patience to take care of it) will become more powerful than the Warrior in a long run. Or something

I've seen a ton of posts on this thread talking about how 3D games are harder to code than 2D ones, but strangely I've seen none talking about how they're harder for the player. Casual gamers don't like 3D games that much. The extra dimension needs to be interpreted through the other two, which makes controls more awkward and can even cause motion sickness. 2D games are easier to play.

2D games aren't dead, but they should be. You can still do a "flat" game in 3D if you want, but you can add so much more eye candy trivially. Also, it really is easier once you have a decent math library going on. I've got a perfect example right here, though you'll have to trust me on the details. Right now my company is involved in two projects for a new handheld. One is in 2D and one is in 3D. Ive been doing engine support for both of them. The 3D one was a breeze to develop and has sailed through to Beta on time with largely only one full time game programmer. The 2D game has more artists and two full time programmers and is (rightly) struggling to get accepted as an alpha. On paper, both games are similar in scope - both are fairly lightweight being aimed at 8yr olds. If you're doing a 2D game because for some reason you don't want to hit the hardware, then great. If you're sticking on 2D under some weird illusion it's easier and cheaper? Well, it just isn't. I would've guessed this if asked a year ago, but my recent experience described above has nailed it on for me. There are far more "corner" cases to deal with in 2D, even if your game is naturally flat. See my tower defense game for how to do a 2D game in 3D and quickly.

Strongly disagree. Take a HO game for example. You could move the camera about and make it all FPS'y and complicated, but there's really no need. You can draw a static scene same as you would in 2D, only this way all the lighting and shadows just works and your fancy effects and polish stuff work properly in the scene (particles going in front/behind stuff, etc etc). A lightning flash at the window could actually look like a lightning flash. The list goes on and on and on. 3D offers you more freedom to make things better, and it also offers you more freedom to make things worse. It's down to how you use it to make sure you don't end up with the latter.

Wow, quite the debate. Personally, I find 2D games much easier and cheaper to program than 3D ones. IMO, the biggest variable is the language, tools and knowledge between the 2 dimensions. As long as you have a basic rendering, sound, input etc. library, 2D games can be made easily from scratch. Add in support for image formats/modifying and the like, and the sky's the limit. You can even find free tools and develop/release a quality game for $0. I'm all for that. For those of you who find 3D game dev easier than 2D, I wish I could say the same, as I'd really like to develop some 3D games. I'm just learning about vectors/matrices now. With game development overall, it's gonna be an uphill battle, as both 2D and 3d each have their pains in the butt.

You should give OGRE a try. It makes it very easy to start with 3D game programming. You can get stuff happening quickly without really understanding all the maths. But it will help to do some cool things (maths also helps with 2D effects / issues too, such as picking on on isometric plane!). Don't be afraid of the maths, vectors are so simple, once you get your head around the basics, you won't remember what all the fuss was about. Matrices are slightly harder, but not much, learn the basics, and the rest falls into place.

I think that about says it all tbh. When you're good at two things, it's silly to say which is easier - they're both easy. When you can do one thing and not the other, the other is always gonna seem hard!. When they're both easy, the question then becomes "which is quicker" and for it's 3D every time ime. I wish you well learning this stuff. My advice would be to not sweat the math too much at this point. All the "hard" bits like rendering and collision detection will be available in a lot of free or cheap libraries. Learn how to use those to do cool stuff, then when you have some comfort level you can think a bit deeper about how it all works.

I've been using matrices all my life it seems, but I struggled with the whole concept until a friend showed me a way to look at them simpler than all the crap that math-heads spout, then it all became a breeze. This is correct in the field of 3D graphics, but not in a general math sense. (The below assumes matrices are kept orthonormalised and orthogonal, which they don't have to be generally but do for useful graphics stuff) The 3 rows of a matrix are simply remaps for axes in world space going to their new local-space orientation The top row remaps the x-axis of your thing from worldspace x (ie to the right) to the direction in which its own "right" needs to end up. The 2nd row does Y (or up) and the 3rd row does z (or forward). X Y Z X 1 0 0 This row is the way "right" will look after the transform Y 0 1 0 This row is local "up" after the transform from world "up" Z 0 0 1 This row is local "forward" " The above matrix is an identity and doesn't do anything when you apply it to a model because the vector in the top row (I call it the X row) is still pointing in the world X direction. The 2nd (Y) row is still pointing to world up. Likewise the 3rd (Z) row is still pointing to world forward. X Y Z X 1 0 0 This row is the way "right" will look after the transform Y 0 -1 0 This row is local "up" after the transform from world "up" Z 0 0 -1 This row is local "forward" " The above matrix is a 180 degree forward tumbling head-stand. X is still facing to the right so you didn't spin around, but now the Y row is pointing down and Z row is pointing back toward you. Exactly what you'd expect if you stuck 3 labelled "X,Y,Z" arrows pointing out of you then stood on your head and asked your missus stood behind you where they were now pointing. For right-handed matrices (OpenGL) just flip the words "column" and "row" above. An OpenGL 3x3 would have the X row down the lefthand side as a column iyswim. No big revelations here, but I remember thinking when someone gave me this 2 minute lecture that I wish I'd read it in all those stuffy "aren't I clever" math books full of sigmas and epsilons. I know one math-head who is pedant enough to state that there's no such thing as "world-space" and end the conversation. He's right, but every programmer on the planet knows what we mean!

I learnt that trick in a university maths course (linear algebra), believe it or not. Only they probably explained it in terms of basis vectors or something, which is not an obstacle if you've just spent half a semester on this stuff, but would be otherwise. Still, I internalised it in basically the way you've described, so that's how I remember it. It also works in 1D and 2D and 4D and any other D you'd care to name, by the way. Bit hard to visualise when you get past 3D, obviously, but the underlying maths is the same.

Whats all the talk about matrices and shaders? All that is not required to do a 3D game better than anyone here on these forums is technically ever capable of. Just get your easy to use 3D system like blitz or unity and away you go: 2D complexity with 3D bonuses. You're adding stuff to make it sound hard. Anyone sane isn't gonna write their own 3D engine these days.

Speak for yourself, noob. Those "easy to use 3d engines" still often require you to know how to use matrices and shaders in order to do things. That you think they don't tells me a lot about you.

Well I can't speak for Unity, but Blitz3D doesn't even *let* you use matrices or shaders, let alone require you. That's not to say that you couldn't write some advanced maths stuff which used matrices internally, but given that Blitz3D already has many built-in functions for matrix operations (eg: multiplying vectors by matrices) all without ever needing to know what a matrix is or that one exists, I think it's safe to say you could write just about anything Blitz3D is capable of without ever needing one.

I've never used a 3d engine that didn't have an accompanying math library or methods in the classes to simplify it all. That said, just because you can construct a Rotation, Translation, etc matrix and multiply a Vector by it doesn't mean that you're sorted. Sure, you can do a lot with that, but you WILL hit a wall where you need to know something you don't. What do you do to get rid of Gimbal lock in Blitz3D for instance? That's without even bringing shaders into it, which are a tool that every 3d programmer needs to have in their toolbox.

I've written seven 3D games, and have never needed to even think about Gimbal lock. Blitz3D already uses quaternions internally, so it will never occur when you tween entities, or in skeletal animation. Given that Blitz3D has bindings for all the major physics engines, which sorts many of the genres where Gimbal Lock could be a user-created problem, there aren't many situations left where it can occur. In the unlikely event that I did need to solve it, I would pick one of the quaternion math libraries available for Blitz3D and use that. Well since Blitz3D uses DX7, you can need them all you want, but you can't have them.

It's probably true you don't need to know the maths at all to bang out a game, even a decent one, but I know from experience that it makes me think in better ways when I make a game. I did a lot of maths at uni, I love maths, but I utterly sucked at it, failed a couple of times, and in the end got through. There have been more then a few times where knowing that maths has helped me past a situation that I couldn't have solved without the knowledge. The maths makes you a better problem solver, dare I say a better programmer.

Good for you - you actually know where to find the tools you need. That tells me you know more about Matrix math than some. If you were standard noob programmer getting into 3d though, you'd have no idea. It's not absolutely essentially to know the maths sure - hell, my 3d math is pretty weak compared to some, but saying it's not at all necessary is a bit much.

We should sticky this I don't mean to generalize, but frankly I have a hard time believing the "3D is hard" peeps here have really dug their heels into any 3D project... Because 3D is so much easier than people generally make it out to be. A lot of the scary math can be used as a black box; yes, even for debugging, because most basic 3D math is VERY simple applications of advanced topics (e.g. finding a determinant for a typical 3D transform is about a million times easier than trying to find a determinant for a general set of coefficients), and most of the math has very recognizable patterns. It doesn't take long to spot a bad transform from a mile away. I mean if someone doesn't like 3D games or is just in a comfort zone and doesn't want to pull out, that's fine... But that's no excuse for people to spread misinformation. Like seriously... "Shaders are hard"? Aren't you guys programmers? Shaders are just simplified programming languages. That's like saying Lua is hard. If I had to guess, I'd say each and every single programmer on this board is more than capable of writing a 3D game. It's no harder than anything else you all are doing.