Planned Features, Limitations

These seem to come up more often than anything else, so I thought I'd preempt having to respond with almost duplicate answers if these questions come up. So these are the currently planned features as they are completed or being worked on or designed.


What will be editable or exposed via scripting?
-Everything. (including file loading, opengl shaders, particles, drawing using raw vertex arrays, etc. *note* this does not mean everything will be done by the time 1.0 is released however.)

Palettes:
-There will be no support for palettes planned in 1.0. (Sorry but it's not the 80's anymore. Instead this is replaced by very powerful and flexible OpenGL rendering capabilities and 32-bit image support.)

Maps:
Only the most basic stuff for now. (Depends on what editor functionality exists I suppose) These include:
-Maps with a maximum of 16 layers. (Technically there is no reason to even clamp this at all except for memory concerns. If you use more than 3 layers though, you are probably doing something wrong.) Any layer can also have opacity and tinting.
-Spritesheets and textures. There is no "image editor" built in. Use photoshop or graphicsgale to edit images!
-Tilesets. Tilesets can be any arbitrary size, however they must use the same texture (non negotiable). Thankfully image sizes of 2048x2048 or more can be suggested, though if you use higher than this some people will not be able to run your quest (game).
-Tiles. Tiles can be any size, *cough* 16, 32, 64 *cough* though every tile must be equal for the entire game. You cannot have one tile 16x16 and another one 128x128. Use sprites instead.
-Animated Tiles: This was almost painful to work out non-animated and animated tiles living side-by-side, therefore all tiles can be animated! The reason I can get away with this and others like rpg or game maker cannot, is because I have over-optimized these on a very low level. :) These are very fast. (I use the term 'fast' here, but my "fast" is not equal to others' "fast". So there should never be any performance issues even on low-end hardware.) ;)
Also they are fairly small, only about 64 bytes in memory. This means that a tileset containing 65535 tiles only uses 4 MB of memory, with 4 + (4 * num_frames) Bytes for animations.
-Sprites. Support for blending, rotations, scaling, animations, etc...

Data Lists:
-Character Classes
-Items
-Monsters
-Monster Groups
-Spells
-Encounters
so far each have quite a bit of space reserved which can be edited and loaded when the game is run.


Everything else: (Under construction) *no code (or interfaces) exists for these yet. I'm working on it as fast as I can!...

Currently working on: Low-mid level and scripting design, along with data saving/loading.
Todo: Menus and Script entities. Battle engine. Characters. Map areas. Rendering.

Quote:

---

Originally Posted by Gleeok

-Tilesets. Tilesets can be any arbitrary size, however they must use the same texture (non negotiable). Thankfully image sizes of 2048x2048 or more can be suggested, though if you use higher than this some people will not be able to run your quest (game).

---

I don't mean to be an idiot, but could you please elaborate on what you mean by 'same texture'? I don't understand what the grain of the image has to do with anything.

Quote:

---

Originally Posted by CJC

I don't mean to be an idiot, but could you please elaborate on what you mean by 'same texture'? I don't understand what the grain of the image has to do with anything.

---

I'm guessing he means that for each tileset, the tiles need to all be on one image file. That way he can load the image into memory and then crop squares out of it based on an X and Y coordinate.

Will Jobs and Character Classes be ,for all intents and purposes, synonymous? Meaning, if you wanted to have Jobs be changeable at will like in FF3 or FF5, will it be done by having the menu alter the Character Class setting?

EDIT: I guess what I mean to ask is will you be able to alter Character Class via the menu?

Quote:

---

Originally Posted by CJC

I don't mean to be an idiot, but could you please elaborate on what you mean by 'same texture'? I don't understand what the grain of the image has to do with anything.

---

Sure, sorry.
Imagine the tiles in zc as a tilesheet, image, or texture (they all mean the same thing pretty much) on your hard drive as a .png file. A tileset is just an arrangement of rectangles and other data from a base image. The tileset itself does not contain pixels or other image data, it just has a pointer to a texture in memory so we know what to draw.
http://www.spriters-resource.com/oth...eriortiles.png

For example, this is a "texture", a tile would be a single rectangle of this texture expressing an x,y,width,height with animation and other data, and a tileset is a collection of tiles in an array. At least this is how I do it. I don't know what other people do if they handle it differently (Actually, I have seen some bad implementations of tiles before, but I'm not counting the bad ones).

The main reason why I won't allow multiple images per tileset is because of performance (also because it is much easier to code). You could say this intentionally forces good mapping practices so people with no idea how graphics cards work won't shoot themselves in the foot. In other words, if you draw a map layer using a single tileset the following is guaranteed to happen by the engine:
1) The rectangular tile region of the screen that needs to be drawn is pushed into a tight array designed for one purpose - to prepare to send directly to the graphics card.
2) When the rendering happens, it sees that no OpenGL state needs to be changed for a very large length of the array, so data does not have to be flushed often, if at all, and the result is the entire contents are sent to the GPU in a single call. Not only is this fast, but it is shit balls fast. :D

Hope that explains everything.

Quote:

---

Originally Posted by bigjoe

Will Jobs and Character Classes be ,for all intents and purposes, synonymous? Meaning, if you wanted to have Jobs be changeable at will like in FF3 or FF5, will it be done by having the menu alter the Character Class setting?

EDIT: I guess what I mean to ask is will you be able to alter Character Class via the menu?

---

Hmm.. I think separate lists for those would be a waste since they do the same exact thing pretty much...though if I missed something then tell me.
Classes are Jobs I suppose...but you'd have to manage it so you can interchange them at will. It's not quite as easy as saying in a script "this.class = white_mage;" but it definately should be doable. ...I just haven't thought about it.

(remind me later when I start the battle engine).

Quote:

---

Originally Posted by Gleeok

a .png file.
http://www.spriters-resource.com/oth...eriortiles.png

---

Ah, I get it now. So you're using texture in the sense that a texture is applied to a polygon, but the 'texture' is actually a tilesheet that the set references (and not, say, paper texture applied to a digital art file). And so the set just crops a specific piece of the sheet when it needs to reference a graphic.

Thank you Gleeok and Glenn for clarifying for me. It is much appreciated.

Holy shit. 16 layers seems incredibly unnecessary, but that is great. Opacity and tinting I can see adding one or two more layers (FF4/5 underwater layers, or fog), making for a maximum of maybe 6 layers. I guess with different opacity layers you wouldn't need Alpha blending, as you could almost achieve the same effect.

Yeah I know, sound ridiculous at first right? The way I see it is this: With any combination of layer color and blending modes (and possibly opengl shaders) there are so many crazy things you could do with tilemaps that I figured why not? I actually did the math on this though -- each layer between 320 and 1280 tiles rendered * 16 layers = 5,000 - 20,000 tiles. On modern hardware I should be able to push at least 60,000 tiles no problem. Though all the layers don't have to be visible at the same, at least.

Are you doing any optimization with your layers similar to what 3D engines do, where only what is visible to the player actually gets sent to be rendered?

I figure if you had an algorithm that would, for each pixel, start at the layer closest to the player and work downward through the layers, doing whatever alpha blending is required, until hitting the first 100% opaque pixel, you would often get away with not considering the bottom-most layers. Then having many layers would become more of a file size issue than a rendering performance issue.

Something related that I learned back when I was making simple 2D engines was that unless something happened in the game which could potentially cause a pixel's color to change, I could save a lot of performance by caching the pixel's color and reusing it, rather than recalculating every pixel every frame.

when I first read it, my thought was that you may want to have "tile properties" be stackable and have 16 for that purpose. For instance, event triggers could be a "layer" (transparent but still a layer), warps could be a layer, etc. But I didn't consider the possibilities of tinting, partial opacitiy, etc. That makes it very interesting.