[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pygame] Hi, I'm new... , isometrics (long)



> > Hmmm, thinking about this isometric diablo-esque
> > engine, would I treat this as a whole bunch of cells
> > that are basically squashed-diamond in shape?
>
> I've been thinking a lot about building a similar
> engine.  What you do will depend on how much you need
> from your world.  More below ...
>

  Cool!

> I'd keep a *very* clean seperation between the
> mechanical game world and the drawn game world, maybe
> even going so far as to have a quick & dirty top down
> 2d representation that you can use for debugging the
> mechanical world independant of the complex graphics.
> When I say simple, I mean simple - labelled coloured
> squares that take 5/8ths of no time to write.
>

  Yes, I am almost up to doing that.  It's especially important here because
not only are the mechanics complex, but I know next to zero pygame.  I'm on
holidays from work for two weeks - so that's good news, deadline += deadline
+ weeks(2) :)  And who says you can't do some paper-coding when your
holidaying?

> Your mechanical and graphical representation will
> depend a lot on exactly what you expect to represent
> in  your world.  Factors such as map size and real
> dimensions play a key role.  Generally, More features
> = more complexity = more cycles to draw.  If
> everything will be displayed as fixed size playing
> peices on a flat map (all same altitude), you can
> pretty much just draw everything in two parts, split
> along the vertical line that's closest to the front of
> the screen (bottom of the diamond) and zbuffer on the
> rear left and right corners of everything to determine
> draw order.

  I'm not sure I am grasping exactly what your saying here.  Are you saying
something along the lines of splitting each sprite which would be placed 'on
top' of each diamond to determine the draw order, then we can just sort of
paste them all on?
  Why..ah.  I was about to ask why the height would affect the draw order :)
  Hmmm...couldn't the engine get away with drawing the sprites from the
top-down, so as to handle overlaps properly that way?  Or am I just totally
confused? (last night was not a good night for me :).

> If you want things to be able to fly
> above the single level, this is not much more
> difficult.  If you want to map really big areas, you
> may not want to use the 2d array of  cells approach
> and instead map surfaces and objects which have x,y
> coordinates.

  Hmm......that sounds like a 'better' way to do it anyway, more flexible?

>  If you want to model a lot of outdoor
> areas, you'll probably want an array type height field
> map, and the problem of what gets drawn in front of
> what becomes more interesting.
>

  Heh heh, well I guess the outdoor areas could be drawn, and interacted
through that way - that would be very cool.  I was thinking of just doing
the outdoor adventures/villages/towns/cities/ports/whatever as a bunch of
events with boxes and wotnot...ha ha, twould be so very good to have it all
done up and moving.  But, if my engine is turn based...bah, it would still
work - each warrior can only do one thing at a time, so turn based would
work fine.
  :)

> > Scrolling...that could be processor-intensive.
> > Perhaps it should jump-scroll, instead of smooth
> > scroll.
>
> Most of the stuff you will be drawing on the screen
> will be imobile, which means that you can render it
> once onto a backing store and not worry about it
> again, until some animation happens on it.  Event
> then, you need only recompute the parts that overlap
> the animation.  For scrolling, this means that you can
> render the scenery in an area (eg) 9 times the size of
> your screen and only animate in the visible section.
> When the screen scrolls, you have a background thread
> that begins repainting the scrolled area out of view.
> A simple mutex can be used to prevent scrolling onto
> areas that aren't painted yet.  It's not perfect, but
> it's enough smoke and mirrors for most uses.
>

  When you say imobile, do you mean that it will be imobile while scrolling?
Because I was/am planning on animating alot of the game screen
(monsters/warriors with idle animations, burning torches, spiders and stuff
cruising around, etc) but pausing it all while scrolling would be fine.
  And yup, that sounds very much like what I was trying to think of doing,
but hadn't clicked yet :)

  Thanks alot,
  Glen.

____________________________________
pygame mailing list
pygame-users@seul.org
http://pygame.seul.org