Archived

This topic is now archived and is closed to further replies.

ancientcoder

Iso engines should be 3D

Recommended Posts

Why suggest to a beginner that Isometric 2D is easier than 3D? This is a big myth. Main reason is the rendering order. I have been involved in a topic on this forum where somebody wanted to draw a sprite that was bigger than two tiles. Sounds simple but a whole bunch of people, including me, responded by telling him to split the sprite up into pieces. Worst of all it required a level of knowledge much greater than getting the hang of a 3rd coordinate and letting the hardware (Z buffering,Span sorting) sort it out. So straight away we get the rendering order out of the way. It becomes a non issue. I am not against 2D but I am against trying to squeeze 3D out of a 2D system when it seems so obvious that ISO is 3D. I have also seen numerous suggestions that you should prepare your 2D game to be moved to 3D when you feel ready. Why? You struggle along and you make your game and have your map up on the screen. All of a sudden you want a sprite to move in pixel units in all three dimensions and the whole thing falls apart. The whole point is that if your game requires any of the following, or is likely to do so then do not even consider trying to develop it in 2D unless you are a masochist. Your sprite can move freely in any dimension and can be bigger than one tile. You can walk under bridges and such like. You consider the presentation layer separate from the physical model. If you are going to write an ISO game then a 2D representation of the data is going to stop you in your tracks. I feel some heat coming my way :-)

Share this post


Link to post
Share on other sites
Well I dunno, I have a 2D isometric game and sprites can be larger than one tile. They can also go under bridges, because they can go between Z levels. They can move however they want. Some things are a pain, yes, but it''s not so bad. I use D3D for HW lighting acceleration, however, although it is technically not aware of the tiles under it.

Share this post


Link to post
Share on other sites
That is fine but my point is about beginners. You managed to do
all these things and so have I but why complicate it?

Go and read the post on objects bigger than two tiles. You may
have a better way of doing it but just read the answers the
poor guy thought it was a simple solution.

You happened to be enlightened but many others are struggling
because 2D to 3D seems such a massive leap. Without a 3D
coordinate system how the heck are you going to walk under
a bridge? This is what a lot of the beginners are struggling
with. They dig out the tutorials write a 2D engine and
wallop the 3rd dimension rears it''s ugly head.

If we are going to suggest anything to a beginner then I
would suggest writing a 2D scrolling game which has only
two dimensions.

Share this post


Link to post
Share on other sites
ancientcoder is right.

ISO2D will always have a place, but above a certain level of complexity, keeping something in ISO2D is counterproductive. For a flat map with terrain and units that occupy the entire tile, ISO2D can handle with no problem. Start getting into objects larger than a single tile (other than building blocks, which are still ok), multiple height levels, and so on, it becomes too much. It should be moved to ISO3D, or should have been ISO3D in the first place.

I have recently been working with Dino Gambone on some ISO3D stuff (some of the examples i''ve made so far have links posted in a recent thread on Mouse Mapping, and i think Dino has his posted somewhere). He is working in OpenGL, and I am working in Direct3D8. What we are working on is coming up with a simple standardized methodology that works for ISO3D, including texture mapping, lighting, matrix-based geometry transformations and z buffering. We are by no means going full-out 3d, as the composition of the world is still, for the most part, tile-based.

Share this post


Link to post
Share on other sites
My first tiled game was a top down scrolling maze game called "Cradle Quest 1: Search for the Holy Cradle" written in QuickBASIC. Downloadable at my web-site because it''s such a classic. That was 6 years ago now and I still use the same general concepts I use for ISO. It''s all tiles, all that''s different is the math placing them and how they''re drawn. Filled rectangles won''t cut it anymore.

Once you understand that ISO is 3D and treat it accordingly there''s no issue with starting with 2D graphics. When Tombstone: Vendetta goes to 3D tiles the render loop will change slightly but nothing else. Not even the tile or map editor which are written using DX6 or earlier and use 2d tiles.

I still recommend 2D to start since if you''ve never done ISO you shouldn''t overload yourself with advanced issues. And you shouldn''t worry about how it looks. That can be easily improved (depending on the design) later when the game itself is done.

3D graphics can be incredibly difficult and expensive to create. Anyone can use Paintbrush.

Ben
http://therabbithole.redback.inficad.com








Share this post


Link to post
Share on other sites
Why shouldn''t you give the "beginner" the choice? If he/she wants to create an Iso rendering engine.. the best way would seem to make it in 2d.. then if it starts to look good, and the programmer is getting the hang of it.. then you can suggest making it in 3d.. 3d is just a hell to start with, so why should you kill the persons creativity with having him dry up while figuring out how to do 3d?

just my .02

Share this post


Link to post
Share on other sites
I am all for giving people choices but when you have had
the benefit of experience is it not better to try and
pass that on?

We all stand on the shoulders of others anyway. Back in 1993
I had no DirectX to use so all the rendering routines had
to be hand coded.

Sure you learn a lot from doing that kind of thing and it
makes you appreciate what is going on under the hood.
But my argument was about people who want to make games
not low level rendering code. There is a world of difference.

Soon Tans and Dino are going to be creating some tutorials
for 3D ISO. I would rather point a beginner to those tutorials
than make them struggle trying to figure out how to get
an object bigger than one tile onto a map. Fundamental stuff
like that should be long gone now.

3D just so happens to solve quite a lot more problems than 2D iso does not. I would point people to the WildTangent driver
or Shockwave 3D if they want to get a game up and running without
worrying about all the 3D math.

I appreciate that if you want to write engines then go do it,
but if you want to make games you should be worried about
gameplay more. If an API makes you worry less about the nitty
gritty then I am all for that.



Share this post


Link to post
Share on other sites
I think the problem is that we''re trying to start beginners out on a rung they''re not ready for. I remember when if you were new you were refered to QBasic. Now it''s C++ and DirectX.

I started using the DATA statment in AppleBASIC. I cut and paste the code for a bug graphic using DATA and made a game out of it. Even used the joystick. I ripped code for that too. It looked neat and impressive (I was 9 or 10 at the time) but even then I thought it sucked simply because I didn''t understand half of what I was doing.

I made Hyperspeed in 1995 which technically sucked (graphics wise, sloppy code, you name it) but was my first big achievement simply because all the code was mine.

That''s nice that a beginner can use a library to make a game but it''s not a really impressive achievement. It''s like using Klick ''n Play.

So really it depends on your method. If you want to just hand out code which allows them to do things that normally they wouldn''t be ready for until they took Trig or Calculus I can''t say I''d support that. If you want to teach them everything involved with how it works (including the math) and encourage them to learn how to write their own library. That would be cool.

Ben
http://therabbithole.redback.inficad.com

Share this post


Link to post
Share on other sites
Let me clarify. I am talking about people who want to
write *games* not engines. Big difference.

Tetris was written with a few ansi characters! It was the
game that was an impressive achievement not the rendering
architecture. Do you think he was obsessed with rendering
order? Did he rewrite the OS''s graphic subsystems and sit
back and think , hey I''m clever I know how the display
works, no he wrote one of the best computer games ever.

A genius could be given "klick and play" and make an
incredible game.

We are talking games here, about people who want to write
games. Sure if you want to write tools and engines then
great, be the next Carmack whatever.

The simple advice I am giving is that do not get hung up
on the toolset. If a 3D api is available, and it solves your
problems, then use it.












Share this post


Link to post
Share on other sites
ancientcoder,
yes I totally agree with you there. I enjoy the creative design portion of game development much more than the technical, and I''m finding that 3D does seem to take care of a lot of problems

Share this post


Link to post
Share on other sites
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

Share this post


Link to post
Share on other sites
If you''re going to completely remove the technical then there''s really nothing for me to argue. It''s like arguing you should make mods for Commander Keen instead of Quake III.

My personal preference is that when I make a game I write the engine for it. I learn a lot more and I know how to better maximize and add to it''s abilities. I also know it does exactly what I want it to and nothing is bloated.

My own engine is going smoothly from 2D to 3D with no major changes in code. Simply because it was always designed to act like a 3D engine.

Ben
http://therabbithole.redback.inficad.com


















Share this post


Link to post
Share on other sites
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?



Share this post


Link to post
Share on other sites
It''s mostly my own. A couple other people initially worked on various parts and then I took over to get it where it is now.

Ben
http://therabbithole.redback.inficad.com





Share this post


Link to post
Share on other sites
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..

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
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.

Share this post


Link to post
Share on other sites
Amen to that TerranFury. I''m not claiming to be a pro or anything. I started with BASIC at age 9 (I''m 17) and made small graphics demos and played around with QuickBasic, QBasic, VBDOS. What tripped me most of the time was the complexity of a big project and that I lost interest after some time. However, those graphics demos were very educational, and I understood pixel manipulation, blitting, XORing, ORing, ANDing sprites, etc. I made my small serious apps in VB 3.0 and started making real apps in VB 5, after which I took up DX7 and did graphics programming again. And the "silly" QBasic stuff really paid off.

My point is that of TerranFury''s. All this "wrapper" and "tutorial" stuff is not doing the newbies any good. It just hides the real stuff from the newbies, who think, ha, a rotating triangle? That''s easy, I just download tutorial xyz from NeHe, and a 3D world is nothing but triangles, so it must be just as easy, and then we have the furious newbies who are angry when we tell them it''s not all so easy.
Ok, that was quite a rant. And has been said a 1000 times before. Damn.

- JQ
Infiltration: Losing Ground
"Simpson, eh?" -Mr. Burns
"Excellent!" -the above

Share this post


Link to post
Share on other sites