I happen to think that every medium and every format (2D/3D) has its issues. In the case of 2D vs. 3D, creating 3D models and such is often a lot harder than drawing sprites, and the code to handle models is so much more substantial than sprites. Use whichever format gets your point across most effectively.

And don't always assume that visual realism is always the best thing. We see realism all around us all the time, and a lot of us like a break from reality when playing a game...

Edited by - merlin9x9 on June 27, 2001 9:24:14 PM

I would argue that there is a certain amount of tech
in writing gameplay code as well. I do understand that
you can get a buzz from writing drawing code and there
is a sense of achievement.

However these days there is far too much to learn for
one person. You could spend a lifetime just learning how
to optimise scene traversal or trying to implement full
occlusion culling.

The next gen of 3D cards are even going to tackle occlusion
culling. People like Carmack and co have asked for these types of things and pro game developers are moving to middleware such as Criterions renderware. Doom3 tech will be licensed, how
you can you hope to compete with this level of investment
and experience?

My problem is that I make a living writing games and acting
as a consultant to people who need a gameing platform. Most
of my work these days is in WildTangent and writing add on''s
to Shockwave 3D in C++.

I am trying to provide a platform that other people can use,
in fact most of these people are not interested in the low
level stuff they want to produce content.

You do have valid points but I could not make a living if
I had to write every engine from scratch.

By the way the vendetta engine is looking pretty cool, is this
your work?

ancient: I agree with you on the "pure" gamemaking, but then you can just give the person a link to DarkBasic & similar products...

If someone asks you how he should make his engine, why should we just give him the "aw.. go ahead and make it in 3d.. I know how to do it in 2D, but it will require to much thinking on your side that it just aint worth it.."

I am kinda defending 2d graphics here, but thats just because I prefer the look and feel of those engines..

I would like to give ancient some good props here since I think the thread he started this on
was one Dino and I asked a long while ago.

I got really frustrated because I wanted freedom within the game world similar to a 3d environment,
such free movement and rotating, but it got very messy with objects larger then tile sizes. I
personally feel that while 3d code may be harder to write, to me it relates more to the game
environment I want, which acts like a 3d world.

I finished the demo in 2d, but I see way more benefits of using 3d then 2d, where a lot are not even related
to just the isometric scene, such as 3d models and animation, 3d terrain, ...

Anyways, the suggestion that was made by ancient and a few others to treat my objects as if in 3d space
was a smart decision then and now. I now have a lil more understanding of how a 3d iso game will work and
thats where Im headed.

I disagree entirely.

Encouraging the use of high-level API''s for people who are just starting out is sending the wrong message. People should learn to code before they tackle a full iso game. Now, making simple games can be part of learning to code (it was for me), but they shouldn''t be in OpenGL or DirectX. Because 99% of the code won''t be theirs; it will be NeHe''s. Why else do you think we get so many posts like "How do I shoot a bullet?" They''re expecting something like: glBulletShoot(vect Dir, GLFLOAT speed). Why? Because they''ve gotten glVertex3f, gl projection, gl lights, and functions for just about everything in-between. I''m not saying this as an expert programmer who wants "newbies" to have to "suffer" through the same things I did; I''m saying it as someone who went down the wrong path; someone who copied code from NeHe, needed a tutorial for everything, and didn''t really know how to code. But I did do one thing right. After a while, I realized what I was doing. I stopped using VC++ for a while, and went back to QuickBasic - with one change: I didn''t use GOTO. Then I downloaded DJGPP, and started hand-coding for Mode13h. And, after a few months regaining my footing, it just clicked. The logic made sense. And why was that? Because Mode13h wasn''t the GDI voodoo I had seen going on in VB. It wasn''t calls to a thousand API functions that looked about as clear as machine code. It was plain, simple logic. Want transparency? Don''t worry about API''s. Just average. Want blurring? Just write your own function: box_blur(unsigned char *buffer); and if it isn''t fast enough, then optimize it yourself, not using nifty hardware functions you don''t understand, but using your head. Unfactor formulae so you can move parts of them to an outer loop. Look at the logic. Come to the realization that programming isn''t voodoo: It''s common sense. For beginners, high-level APIs don''t foster that impression. They instead encourage the belief that, for every problem, there''s a function in some header file. APIs are powerful tools in the hands of more experienced programmers, and can even result in some impressive-looking creations at the hands of "newbies." But, too often, they discourage real understanding.

Beginners should use DOS Mode13h. It doesn''t have any of the DOS VESA complexities of bank switching or setting up the linear frame buffer, and it doesn''t have any of the windows complexities of setting up and dealing with a window, or even using an API. All it is is moving data around. That''s it. You code the math; you code the logic; you learn to understand the language and the logic because _you_ wrote it.

And once you get on your feet - perhaps after being knocked down like I was - then move onto Windows API programming. Use it. Understand it. Get to know some GDI functions. Understand them. Then move onto OpenGL/Direct3D or DirectDraw. And if you do, don''t rely too heavily on the special features. Your sprite goes off the screen? Don''t run looking for a special library function. Just change the dimensions of the rectangle yourself. Your sprites draw in the wrong order? Come up with a solution. Code a sort for them, or draw them as you draw the tiles. Reinvent the wheel. Just understand what''s going on, and, after a while, everything will become much easier. Because it''s programming, not pasting.