Omnimaga > Escheron: Twilight over Ragnoth

"Escheron: Twilight over Ragnoth" — progress updates and discussion

<< < (3/41) > >>

Escheron:
I have no desire to use IRC ever. Sorry. It shouldn't be that much trouble to collaborate the details through email, though. (or even through this thread, actually)


That aside, something I always have trouble with is setting up a status screen. Here's a concept of what I have so far, but the text isn't actually aligned according to how the game would normally handle graphics tiles. I believe everything has to align to a 4x4 grid, but I moved some text over a couple of pixels in this case.

I want to have one ubiquitous status screen that outlines all relevant details, maybe including elemental and status resistance properties. I suppose those aren't absolutely necessary though.

EDIT: Actually, I messed around with the status menu some more, and I like the results so far. I've also worked out some ideas for other sub-menu screens, such as the equipment screen.

Iambian:
Just a quick note, we're not limited to a 4x4 pixel grid anymore. We've got a real font routine going on and since this is a black/white game, speed isn't really that much of an issue.

That should make it easier to design stuff.

Escheron:
I found a nice tileset earlier that I think I'll incorporate into the game. The dithering works well for purely B&W detail. I would like a second opinion, though. Do you think the character sprites go well with these tiles? I didn't dither any of the sprites because I was afraid it would cause them to blend with the background too much. I figure having more pronounced white pixels will help keep the sprites apart from the background tiles.

Incidentally, this tileset seems like an improvement over the one I was using previously. Areas look much less... square?

What sort of upward limit is there on the number of tiles in the tileset, and the resolution of maps? I may be able to squeeze 128 tiles, but a limit of 256 would certainly be generous. Maps should be no greater than 128x128, but I may be able to squeeze 64x64.

The number of maps may be slightly smaller since I have a new idea for handling indoor areas such as shops. For the most part, walking into a door leading to a shop will just bring up a shop menu instead of having you explore a small room and having to walk up to the shopkeeper to initiate the shop window. Given the resolution of the screen, it's actually very difficult to create a room that has both counter space and a shopkeeper standing behind it, because part of the tiles gets cut off. I figure my approach makes a bit more sense. Some areas will still have explorable indoors though, such as taverns.

Iambian:
Given the images shown, I think the tileset looks nice. I'll wait for a third opinion (geekboy) and see what he's got to say. I personally like the dithering on the background tiles.

The engine allows up to 64 unique tiles per tilemap, but may have up to 256 different tiles to a tileset. It's entirely possible to support more than that (so long as we don't back-reference a previous 256 tile chunk, duplicates allowed to help avoid back-referencing) but then we'll be doing shenanigans. The engine supports shenanigans. Note that things such as NPC's and sprites don't count as tiles. Our engine supports completely separate sprite entities, so if you absolutely need to exceed that 64 uniques per map, you can shore up the remaining with positioned sprites. Up to 256 different sprites, tho we can do shenanigans with that limit too.

Tilemaps (at the moment) are only 32x32, but may be allowed up to 64x64. We'll have to drop all pretenses of support for the original 83+ to have 128x128 maps (not that we intended on supporting those calculators anyhow). Maps larger than that will require an addition to the map abstraction module in the engine. Totally doable, tho definitely not general-purpose.

As far as shops go, it's perfectly fine to try to allow shops to have counter space and a shopkeeper behind it. While we haven't yet shown it, We have hotspot-based camera panning and offset to let you see both at the same time. I'll have to whip up something to demonstrate this.

EDIT: The screenshot below demonstrates a modified version of geekboy's text engine, along with scriptable hotspots. These hotspot can (though not explicitly demonstrated) distinguish between activation via walk-on versus talked-to (2nd key interaction). Talked-to was demonstrated with the statue, and walk-on was demonstrated both by the black-square-on-walking-on-a-certain-path and the shop camera panning hotspots.

Escheron:
128x128 won't be necessary. 64x64 should be generous enough for the world map. I assume looping around maps is still possible? Only the world map needs to support this feature.

I can't foresee any instance of a single map containing more than 64 unique tiles, but the tileset itself may be just under 200 tiles total. I'll try to keep it down to 128, but I can't say just yet. I'm trying to be a little more efficient with the world map tiles. Instead of 6+ tiles used to make one forest or a series of mountains, I'm going to reuse the cave tileset to create mountain ranges (which does look a bit like the mountain tiles from early FF games) and maybe 2 or 3 tiles for forests.

A couple of other things to note: There are no animated tiles anymore, and there's no need for sprite transparency ever. With the way the water tiles are dithered, the screen's intrinsic ghosting effects will make them seem almost animated. Plus it would be awkward trying to animate dithered tiles anyway. I mean, there are so many pixels close together.

As for sprite transparency, I just don't see the need. Since everything is B&W, I'd have to draw a white halo around sprites to keep them from blending with the background, which itself leaves only 6 or 7 pixels around the sprite that end up being transparent. Besides, all of the floor tiles are mostly white, with no solid-black floors anywhere in the game.

Navigation

[0] Message Index

[#] Next page

[*] Previous page