3D vs. 2.5D -- opinions solicited
Joseph J. Strout
2.5D environment. That is, the pieces move around on a hilly terrain.
Sometimes there will be more than one possibly "ground" level for a given
lattitude and longitude -- e.g., a bridge over a gorge -- but I don't
expect there to be tunnels and such. The terrain will be modified by the
action (craters formed, bridges built and blown, rocks moved, etc.) The
pieces (little humanoid guys) are going to be large, colorful, and
dangerously cute, the cartoonlike animation being one of the initial
attractors of the game.
But I can't decide whether to do it in real 3D, with a roving camera, or in
2.5D with an isometric view. Some considerations I've thought of so far...
2.5D:
- requires less horsepower, so smoother play
- precomputed graphics may be higher-contrast and easier to visually parse
- easier to get an overview of the battlefield
3D:
- very much in fashion these days
- allows you to zoom in for a closer look at your pieces
- may improve user engagement
- likely to be MUCH slower on low-end machines
I'm inclined to think a 2.5D view is more appropriate for a game like this,
from a gameplay standpoint. But 3D is popular. Any thoughts?
Thanks,
-- Joe
,------------------------------------------------------------------.
| Joseph J. Strout Department of Neuroscience, UCSD |
| jst...@ucsd.edu http://www.strout.net |
`------------------------------------------------------------------'
Jason Main
that you will want to do transparency, to remove the posibility of important
idums being hidden form view. Also with the everything-3D-wether-it-works-
or-not attitude of today 2D games have to really shine to stand out.
-Jason Main
Amit Patel
| I'm tinkering with an idea for a war game which takes place in basically a
| 2.5D environment. That is, the pieces move around on a hilly terrain.
| Sometimes there will be more than one possibly "ground" level for a given
| lattitude and longitude -- e.g., a bridge over a gorge -- but I don't
| expect there to be tunnels and such. The terrain will be modified by the
| action (craters formed, bridges built and blown, rocks moved, etc.) The
| pieces (little humanoid guys) are going to be large, colorful, and
| dangerously cute, the cartoonlike animation being one of the initial
| attractors of the game.
|
| But I can't decide whether to do it in real 3D, with a roving camera, or in
| 2.5D with an isometric view. Some considerations I've thought of so far...
|
| 2.5D:
| - requires less horsepower, so smoother play
| - precomputed graphics may be higher-contrast and easier to visually parse
| - easier to get an overview of the battlefield
Yes, Yes, Yes!
| 3D:
| - very much in fashion these days
Of course this only matters if you are trying to make a lot of money.
If you're going to be doing this for yourself, or if you're selling to
a small (wargaming) crowd as opposed to the mass-market Myst player,
it's less important to be in fashion. In small communities, I think
it's easier to stand out based on good gameplay.
| - allows you to zoom in for a closer look at your pieces
You could also do this with 2.5D, by providing bitmaps at several zoom
levels.
| - may improve user engagement
| - likely to be MUCH slower on low-end machines
Ask yourself: As a player, what information do you want about the
battlefield? Do you get that information from the simpler 2.5D view?
If not, which aspects of a 3D view would help? Zoom? Rotation?
Different camera angles? You might be able to put enough into the
2.5D view to let the player see what he wants to see, and then 3D's
benefit would be very small.
| I'm inclined to think a 2.5D view is more appropriate for a game like this,
| from a gameplay standpoint. But 3D is popular. Any thoughts?
I think 3D would steal CPU cycles away from gameplay (and AI). :(
Use all the saved CPU time to run a Python interpreter instead!
- Amit
Choo Chi Yen
this,
>| from a gameplay standpoint. But 3D is popular. Any thoughts?
You may want to also take a look at Railroad Tycoon II's new engine at
http://www.poptop.com .
Can't really pull much info from there, however, an interview with Phil
Steinmeyer of PopTop done by GamePen
(http://www.gamepen.com/pc/railroadtycoon2/interview-2.html) showed some
very impressive screenshots. They seemed to be able to use 3D in a 2D
approach, getting the best of both worlds. :)
Below is a quote from Phil:
<quote>
"I wanted to create an engine specifically geared to strategy games,
with
outstanding visuals, great zoomability, and the ability to view a LOT
(hundreds or
thousands) of objects on the screen at once.
So I created the S3D engine, which runs at 1024 x 768 resolution, in 8
or 16 bit
color, using polygons for the ground and sprites for objects. It looks
great and
allows us to get a lot of polygons on the screen at once (up to
300,000). It
rotates and zooms. It can display a lot of objects at a time, and the
objects
don't have that blocky polygonal feel. I think the results speak for
themselves.
Perhaps the biggest drawback is that allowing rotation forces us to do a
lot more
work. We have to create 4 times as many frames of every object. It’s the
only
major design feature of the engine that I've had second thoughts about,
but on
balance, for this game, I think it adds a lot and is worthwhile."
</quote>
Don't really understand what he means in the last paragraph though, no
demo yet.
>I think 3D would steal CPU cycles away from gameplay (and AI).
>Use all the saved CPU time to run a Python interpreter instead!
Is Python interpreter really that fast and small? I mean to be used for
writing AI scripts in games?
Do you know of any existing games currently using embedded Python
interpreter?
Please, I need to know.
Thanks.
Chi Yen
Joseph J. Strout
<cho...@hitech.com.my> wrote:
> Below is a quote from Phil:
> So I created the S3D engine, which runs at 1024 x 768 resolution, in 8
>or 16 bit
> color, using polygons for the ground and sprites for objects. It looks
>great and
> allows us to get a lot of polygons on the screen at once (up to
>300,000). It
> rotates and zooms. It can display a lot of objects at a time, and the
>objects
> don't have that blocky polygonal feel. I think the results speak for
>themselves.
It does look great, but how do you zoom sprites? Just store them big and
subsample to zoom out?
> Perhaps the biggest drawback is that allowing rotation forces us to do a
>lot more
> work. We have to create 4 times as many frames of every object.
Well, this is standard for 2.5D engines, right? If you want to view from 4
angles, you have to have 4 views of each object.
Richard Mitton
>2.5D with an isometric view.
Maybe you could use a raycasting method to draw the landscape (like the
famous Mars demo, but obviously less hilly and more realistic). Objects
could be placed on using a z-buffer or something.
This way, it would be 3D enough to allow rotation etc, but should still run
fast.
-------------------------------------------------------
Richard Mitton,
ric...@farout.demon.co.uk
-------------------------------------------------------
Levi Paul Cameron
> [...]
>
> Maybe you could use a raycasting method to draw the landscape (like the
> famous Mars demo, but obviously less hilly and more realistic). Objects
> could be placed on using a z-buffer or something.
>
> This way, it would be 3D enough to allow rotation etc, but should still run
> fast.
>
Actually the mars demo didn't use raycasting: it drew the land in
slices perpindicular to the view from farthest-back to closest and to
achieve the shading interpolated the colours in vertical scan lines
between each land slice. The net result: If you tried to rotate it, you
got *really* bad artifacts on the screen (as I found out when I tried to
do a mars that rotated and I also saw one someone else's that suffered
the same problem). There is a way around this: when you get the height
of the land at (x,y) don't round x & y to integers but instead
interpolate between the four points around this (x,y), and make the
slices closer together. You then kind of destroy the speed of program
(and textures aren't really possible with this method).
Raycasting would work, but if you are going to get smooth (non-blocky)
land you are either going to have to have an ultra-high resolution map,
treat the land heights as the corners of polygons that you then test for
intersections with, or use some sort of vector (as in image vectors not
math vectors) system for calculating the intersections.
My advice: stick to polygons.
Levi Cameron
l.cam...@ugrad.unimelb.edu.au