Jump to content


Develop time: 3d or 2d?


8 replies to this topic

#1 Eduardo

    New Member

  • Members
  • Pip
  • 2 posts

Posted 16 January 2008 - 07:15 PM

Hi, I've been working on a design document for an tactical RPG game for a couple of weeks now, and I got to a point where I must define if my game is gonna be either 2d or 3d.

The game is going to have an isometric view with very small models for the characters (so lots of details or large poly count are not necessary) and my question is this one: what kind of graphics would be faster (not necessarily easier) to develop for a solo programmer (though I might add a couple of friends to the project later on), assuming I'll use an 3rd party engine?

I think 3d would be better because the game will have lots of different characters, and animating them in 2d would be a PITA, but making the world (which will be pretty big) would probably be easier in 2d, due to the time it takes to model and texture the landscape and buildings.

So, what do you think?

#2 Mattias Gustavsson

    Senior Member

  • Members
  • PipPipPipPip
  • 413 posts

Posted 16 January 2008 - 07:34 PM

Developing a 2D game is much quicker than making a 3D game. I'd go for 2D (but then again, I *always* go for 2D :D )
  • www.mattiasgustavsson.com - My blog and current projects
  • www.rivtind.com - My Fantasy world and isometric RPG engine
  • www.pixieuniversity.com - My Software 2D Game Engine

#3 .oisyn

    DevMaster Staff

  • Moderators
  • 1842 posts

Posted 16 January 2008 - 07:35 PM

You can always just prerender the sprites for the characters. Sticking to 2d doesn't mean you can't model and animate them in 3d. A lot of 2d games do it that way.
C++ addict
-
Currently working on: the 3D engine for Tomb Raider.

#4 fireside

    Senior Member

  • Members
  • PipPipPipPip
  • 1587 posts

Posted 17 January 2008 - 02:53 AM

It really shouldn't be that 2d is faster, but it is. There just isn't a 3d engine around that doesn't take quite a bit of work to get set up even though a lot of them advertise to do that. If they do, they end up forcing you into doing a mod more than a game. Plus you'll get overwhelmed in so many things like bump mapping, effects, path finding, physics, etc. that you'll forget about writing a game. Like was suggested, though, it's better to make 2d sprites in a good modeler that does bone animation. 2d animation is very hard to do and is becoming a lost art. Also, this would be a huge project and if it's your first game, is a very bad idea.

#5 Mattias Gustavsson

    Senior Member

  • Members
  • PipPipPipPip
  • 413 posts

Posted 17 January 2008 - 09:27 AM

Exactly. With 3D, you will most likely get caught up with the tech side of things, never getting around to work on the actual game.

Me, I use Poser to do my art (3D objects rendered to sprites) and my 2D game engine which is designed for fast development speed and stability. :yes:
  • www.mattiasgustavsson.com - My blog and current projects
  • www.rivtind.com - My Fantasy world and isometric RPG engine
  • www.pixieuniversity.com - My Software 2D Game Engine

#6 Eduardo

    New Member

  • Members
  • Pip
  • 2 posts

Posted 17 January 2008 - 10:24 AM

So if I render a 3d model to a sprite and then put it on my 2d background (I'm guessing this is what games like diablo 2 and starcraft did right?) won't I have to use a special modelling/texturing technique so that my models won't look out of place on a pixeled background?

And yeah, I started thinking about this project and I think it is too big for my first serious game (it's so easy to get carried away when you're inspired =p), so I'm toning it down.

edit: Can you guys recommend me a 2d engine with good documentation/support that can be used with C# or with a scripting language? I don't wanna deal with C++. Too fugly and bloated for my tastes. Thank you in advance =)

#7 Wernaeh

    Senior Member

  • Members
  • PipPipPipPip
  • 368 posts

Posted 17 January 2008 - 02:39 PM

There are some things you should be aware of that are important for percieved "flow" of images.

First: Use the same "detail level" all over, unless there is a reasonable argument against it:

In 3D this means, you should keep up a rough overall "texel to world" ratio. If the floor of your terrain at certain places has more texels, thus looking sharper, than at other places, where a texture is more stretched, this gives a wrong percieved "depth". The eye expects objects at a certain distance to share sharpness.

For 2D, this means you should try to have a 1:1 ratio for your backgrounds (don't stretch anything, shrinking generally is okay). Also, if your meshes are crispy, your backgrounds should be crispy as well. If your meshes are more "smoothly styled", your background should be as well.

This partially also runs into the second argument: A consistant graphics style. Rendered meshes on hand-pixeled background (tend to) look weird. Cel-Shaded meshes in a 3D textured environment with normal textures look weird. And so on.

The third one: Perspective and lighting.

For 3D, you may get (slight) weirdness in your graphics if your meshes use different lighting solutions than your background, i.e. buildings are lightmap-lit, meshes are vertex lit. Can be observed in many older games, UT, and similar, since it looks like meshes and surroundings being exclusively lit by different sources.

This is true for 2D as well: Be careful that your light comes from a certain, set direction. The eye uses lighting as a hint for percieving depth on a flat surface (think of the simple shaded cube that can, on a paper, either be seen as extruding from the surface, or extruding into the surface).

Doing perspective in 2D is more difficult, especially if you intend to have some sort of rotating camera. Basically, a normal "top down" view shouldn't show anything but the head of people. Usually, this is remedied by "simulating" a slight vertically shifted, parallel projection, i.e. one sees both the front and the top side of objects. Be careful to stay in this (or another, as you desire) perspective for all your graphics, don't drop out to full isometric, or to full topdown for any.

The eye is very compatible here though: Certain small conflicts in either perspective or lighting are gracefully ignored. If you remember the dungeons from the first Zelda game, the dungeon frame (outer walls and doors) had a different perspective from the one used for objects and walls inside the room, which wasn't all too noticeable.

Maybe have a look at SDL (which is pure C), but it is more of a image library/rendering engine than an actual game engine. Allegro used to be free around the time I did 2D stuff with middleware engines, haven't checked on it for quite some time, though.

Hope this helps,
Cheers,
- Wernaeh
Some call me mathematician, some just call me computer guy. Yet, I prefer the term professional weirdo :)

#8 monjardin

    Senior Member

  • Members
  • PipPipPipPip
  • 1033 posts

Posted 17 January 2008 - 03:38 PM

Eduardo said:

Can you guys recommend me a 2d engine with good documentation/support that can be used with C# or with a scripting language? I don't wanna deal with C++.
Take a look at Python and pygame. It's fairly easy to transition to C/C++ later since pygame is based on SDL. There is also a project called SDL.NET that provides .NET bindings for SDL. You could use that with C#, but I don't know anything else about it...
monjardin's JwN Meter (1,2,3,4,5,6):
|----|----|----|----|----|----|----|----|----|----|
*

#9 fireside

    Senior Member

  • Members
  • PipPipPipPip
  • 1587 posts

Posted 18 January 2008 - 12:47 AM

This is a little odd of a suggestion I guess, but take a look at Wintermute. It's an adventure game engine, but they aren't all that different when you think about it. It has built in path finding, screen scroll, and a lot of other nifty little features. There might be an rpg engine that better suits, but I've used Wintermute and it's pretty cool. I'm an adventure game fan, though.





1 user(s) are reading this topic

0 members, 1 guests, 0 anonymous users