Thread: Pokemon: Azure
View Single Post
  #6    
Old July 27th, 2011 (05:18 PM).
Awkward Squirtle Awkward Squirtle is offline
,@,e .ºoO
 
Join Date: Jul 2011
Gender: Male
Posts: 110
Neato. As I said, my engine hasn't made much progress either... This project should give me some motivation :P

I just looked at Four Star Mon's forums (this is the C++ project you mentioned, isn't it?). It looks like I'm using the same language and media library as them now (C++ with SFML)... This should be interesting.

How are you doing the 3D map editor? Is it tile-based?
I started work on a map editor for my engine; the plan was to render it orthogonally from an angle, then stretch it to give a square grid. I'm still unsure on how to handle changing and representing z-values (maybe some kind of brush tool that you drag up/down to raise/lower terrain?). I was planning for tiles to be assigned as 'hill tiles' which would automatically raise/lower terrain when placed in a closed loop; user-defined height changes would be added on to this 'default' heightmap.
I may as well describe my map system (most of it isn't done yet). Each tile has a z-coordinate applied to one corner; the other corners use z-coordinates of neighbouring tiles. As well as basic flat tiles, I also have a type of tile that would be stored in map data as an ordinary tile, but rendered as a 3D model (used for things like cliffs and fences), and a type of tile that would be billboarded (used for grass and small rocks). In addition to multiple tile layers (currently 2, but in theory, unlimited), I also have three more layers: a tree/simple object layer, a building/complex object layer, and an event layer. The tree and building layers are similar, and store the IDs of models to be rendered as part of the terrain; the difference is that the tree layer stores them as tiles (in an array the size of the map), while the building layer stores them in a list (each building stores its own coordinates). Buildings also affect passability differently (depending on relative z-coordinates; this makes bridges quite simple). The tree layer is static and loads/renders faster and uses less memory than the same number of objects in the building layer; the building layer is more flexible. The last layer is the event layer, which simply stores any NPCs and interactable objects.
How does your map system work?

For events, I see you're using scripting. Is this difficult to implement? At the moment, I'm using a system like RPG Maker that has a bunch of preset commands. This has the advantage of being quite easy to use, but isn't as flexible (a good selection of commands, including things like selection and iteration, should mitigate this).

Also, in the first post, it mentions an 'innovative UI'. Am I correct in saying this will be mouse-controlled?

There's a library called Monogame (I think) that lets you port XNA games to *nix systems, which was what I was referring to. You could look into that later.
Reply With Quote