Archived

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

making an RPG: ISO, 3D, or both??

This topic is 6013 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

I''m going to write a RPG together with a friend, my friend is an artist and I''m the programmer. We both write the story, mostly him but anyway I think it should be Isometric, since (almost...?) all RPG''s are. He prefers fully 3D, since he really hates that he have to make tiles. He wants to draw the whole town in one run, a big image. How is that done? If I could do exactly what I wanted, then I would do a 3D iso. Except I don''t have a clue on how that''s supposed to be. I''ll wait for TANSTAAFL and Dino to finish their project Neither of us have any experience with this so you guys with experience, please give some advice of what''s better/easier. (this is also gonna decide wich book to buy. An ISO, you all know which one , or an 3D) Please help! }+TITANIUM+{

Share this post


Link to post
Share on other sites
*hmmmmmm*

Making an RPG like GTA (the camera angle in 3D), but rotate it to be like . Would that be very difficult?

It would be like 3D isometric... So what should I buy, an Isometric book, or an 3D one? Need the 3D one more I think.

But how should I start? First make a "normal" Iso engine in DX8, then change some classes/functions here and there so it becomes a 3D one?
Is it possible to devide the engine like that?? All the extra things like fighting, story telling, etc, and all that "fun stuff" are completed and working with the 2D iso. Then just change the graphics part (and maybe the path-finding algorithm to work in 3D) without changing anything else in the program?

Because that would be great! Do a 2D iso game, then change the graphics to 3D. (using DX8 from the start, it''s actually is 3D when it''s 2D. right?)

}+TITANIUM+{

Share this post


Link to post
Share on other sites
How long have you thought about the design of your game? Makeing a rpg will bring you into GREAT trouble:

Thousends of thousends classes which all relate with each other:
Inventory, Char Stats, Battle System (trust me makeing a little battle system alone is an nearly impossible difficult thing too do), Overword Map, Location Map, Grafix&FX, File I/O, Gamelenght, AI.

If you want to start gamedevelping then i recommend to do something much simpler e.g. trie to make a clone of the FF5 Battle System.

Share this post


Link to post
Share on other sites
hehe, I know it''s difficult.

I''m writing the game with a friend. And there probably be at least one or two more to help me with the coding. But that''s something I _have to do_, the game MUST have a battle system, inventory, etc...

My question is: Should I write it in complete 2D (Iso), or should I do a 3D (overheadview), or combine the both and do a 3D Iso?
And: How hard is it (with DX8) to go from 2D to 3D?? Do I have to rewrite the whole game? *hope not*

}+TITANIUM+{

Share this post


Link to post
Share on other sites
Wow, sounds like you are doing the exact same thing as me: writing an rpg with another person to do graphics etc. I started out writing the whole thing with directdraw, and made a 2d isometric graphics engine that worked fairly well.
When I saw Tan''s book I thought, wow, this is exactly what I''ve been doing. I bought it, read through much of it, and decided it was too easy. So I decided to skip to the last 2 chapters where he goes into 3d, fell in love with the idea, and started over with a 3d engine.
Now, about a week later, I am smacking myself for switching to 3d. I didn''t think it would be that much harder. I was wrong, at least I think so right now. Probably the learning curve is just quite steep.
I must say, however, that I find D3D8 much different from anything I''ve done in directdraw. It would therefore not be an easy matter to convert code from dd to d3d. It really depends what you are looking forward to most to code. If you want to write the graphics engine and see pretty pictures on the screen, you should program your engine in d3d. If you want to work more on the ai, inventory, scripting, story developing etc, use dd to jump over the graphics hurdle quickly.
I have found that there is a fine art to keeping your artist happy and thus working for you. If you make too many demands, they sort of give up and you don''t have an artist anymore, or at least not one that produces useable graphics. D3D is a lot easier on your artist because they can just make rectangular textures, rather than isometric tiles. D3D then takes care of the rest.
Alright, I''ll quit before I babble on any further. In the end, it is basically a matter of choice whether to use dd or d3d. Do what you think you can handle. If you have questions or such, you can reach me at jzeppenfeld@excite.com
Good luch, and have fun programming,.

Share this post


Link to post
Share on other sites
damn... D3D is THAT much harder then DD huh?

But either way, I''ve ordered TANSTAAFLs book. It should be here in a week. I''m gonna read through it. But it uses DX7, I was hoping to the exact same things with DX8. Is that waaaay to hard? *hope not* Ordered Beginning Direct3D Game Programming too, I know it full of typing errors but anyway. Hoping to combine those two books

Because doing it in DXGraphics even when doing 2D iso, I''m hoping that I can jump to 3D iso without having to recode everything else.

Like you said, I want to concentrate on AI and such. When I''ve got that working, I might do the graphics a little prettier. Hope you understod me

}+TITANIUM+{

Share this post


Link to post
Share on other sites
A wrapper is simply a set of functions that make it easier to work with something. The zero-one spritelib is a wrapper for the d3d sprite object. It really doesn''t add any functionality, it just makes it more user-friendly.
One thing about wrappers: They generally have some overhead associated with them. If you need your code to run faster, you should usually use the most low-level functions you can get your hands on.
Hope that helps.

Share this post


Link to post
Share on other sites
oh I get it! thanx!

Didn''t understand one thing though. Are Wrappers "more lowlevel"/faster than using the actual DX functions?

}+TITANIUM+{

Share this post


Link to post
Share on other sites
A wrapper works like this:

First there is an ugly complicated DirectX function with lots of parameters (I''ll make up a fake one):

DirectXUglySurfaceFunction(handle, surface, rectangle, flags, unusedvariable, unusedvariable2);

You want to use this function a lot to do a SurfaceTweak (again, this is a pretend action you want to do), but dont want to have to remember all the crazy parameters, so you write your own function that calls the DirectX one:

MySurfaceTweak()
{
DirectXUglySurfaceFunction(handle, surface, rectangle, flags, NULL, NULL);
}

Now the DirectX function is wrapped! (Yeah, inside MySurfaceTweak you will have to handle all those DirectX parameters, but outside you won''t - at least not all of them)

Your code will just call MySurfaceTweak() and the DirectX call is hidden within it - it is wrapped.

Now, you tell me - is a wrapper more low level and faster than the DirectX call?

(BTW, TAN''s book does a great job of using wrappers to do exactly this kind of stuff.)



Dash Zero
Credits: Fast Attack - Software Sorcery - Published by Sierra 1996

Share this post


Link to post
Share on other sites
Nope, other way around.
Usually when something is easier to use, it''s slower. A wrapper makes something easier to use by adding "standard" code. i.e. Most things in d3d are always initialized the same way. A very basic wrapper would take all of these things and take care of them, so that all you would have to do is call a single function to initialize everything. This cleans up your code, but also adds another function call, which makes your code run more slowly.
(It is easier to understand initialize_d3d() than to read a whole list of declarations and calls that create your d3d object, your device, your matricies, your vertex-buffers etc. Basically all a wrapper does is move functions you would call anyway into another function, so that the original function looks less cluttered. The same stuff happens, but using someone else''s wrapper doesn''t require you to understand in depth what is actually being done)

Share this post


Link to post
Share on other sites
hehe... Lowlevel... Don''t know exactly what that is. But my gues is that it''s "as close as you can". And wrapping (tweaking) isn''t it!

Isn''t it better with a #define ? The precompiler replaces the code when compiling so when it''s running it''s "low level". Instead of calling a function that calls a function (wrapping). Isn''t that better? *hmmm, dunno*

Share this post


Link to post
Share on other sites
Low level basically means closer to the hardware. Assembly is considered a low lwvel language - C is a higher level language. In windows programming, DirectX interacts with the hardware, so all you programming is fairly "high level".

Your compiler optimizes as as best it can, so a wrapped function probably works the same as an unwrapped one once the compiler is done with it.

I would suggest you stop trying to worry about how fast things are and worry about things like design and architecture and maybe even building a prototype to see if your game will even be "fun".

The book I read before TAN''s was called ''Game Architecture and Design''. I think it is a great reference to help you see the big picture. Check it out.

Dash Zero
Credits: Fast Attack - Software Sorcery - Published by Sierra 1996

Share this post


Link to post
Share on other sites
I''ll see if I can get a hold of that book! Have already 2 on the way (TAN''s and the "Beginning Direct3D") so I have enough to read already.

I''d really like to get my hands on Game Programming Gems! Is it good to have right from the start, or is it better when you''ve already tried things for yourself? I mean, "the most common problem among programmers is that they all ''invent'' the same algorithems instead of taking the ones that exist and optimize them" (or something like that, read it somewhere)

Just out of curiousity. Is #define "better" than wrapping in a function?

}+TITANIUM+{

Share this post


Link to post
Share on other sites