Wesnoth II - Wesnoth 3D.

[Darker_Dreams]

I was thinking about using pngs for the terrain and units... Like I posted before... Maybe be a bad idea tho...

From what I've seen doing proper 3d is actually going to be easier and get you more for your work. There's a resource concern (ie; processor and graphics speed) but that's something that can be managed else-wise.

Ironically, what you're describing is going to become doable as wesnoth gets the different facings for the units. A logical next step would be to add additional facings for the appropriate terrain and "suddenly" you would be able to rotate the map 360 degrees. Cool, but not "3d."

[TheBuzzSaw]

I still think an OpenGL-based 2D Wesnoth is the next logical step...

[johndh]

To expound on my previous post: If you're just talking about taking 2D renderings of 3D models and using those instead of sprites, then you'd be completely missing out on what makes 3D good to begin with. With 3D, you can zoom, pan, rotate, and get all sorts of camera angles, and even perspective (stuff that's far away looks smaller, etc.).

Anyway, small update to the mockup. Added a castle and a bridge.

[dipseydoodle]

Cool johndh... sorry I couldn't post any sketches the other day, maybe I'll get some sketches up today.

Hey Buzzsaw. Welcome to the forums... I have played a few games with OpenGL but I'm not always impressed by them(most of them are for macs so that could be the problem)... It looks almost like a polished up 80's-90's IBM game... I do love retro
graphics tho.

[johndh]

I have played a few games with OpenGL but I'm not always impressed by them(most of them are for macs so that could be the problem)... It looks almost like a polished up 80's-90's IBM game... I do love retro
graphics tho.

Oh really?

[dipseydoodle]

WOW... Ok, I was wrong... Not that bad.

[Alink]

Yeah, all the id Software engines are OpenGL based (even if the upcoming Rage will also support DirectX). In fact, any games having a Mac (or PS3) version should also have OpenGL support (e.g. Half-life 2, World of Warcraft...). But that's just unimpressive retro games

For a multiplatform games, only OpenGL makes sense and it has the same rendering power as DirectX (on PC, because on other OS, DirectX has nothing)

@dipseydoodle: sorry, I know you already admitted that you were wrong, but I wanted to clarify this common misconception (probably caused by Microsoft propaganda)

[dipseydoodle]

No problem... Oops!

EDIT: TheBuzzSaw, sorry I offended you on your first post.

EDIT: Sorry for the late post... This is a sketch I was thinking of....

Every triangle equals another hex or whatever you want to call it... The elevation would be done by using some kind of code that goes inside the map... I'm guessing...

[johndh]

I'm not sure what you mean. Personally, I think the best and easiest way would be to just use Wesnoth's map editor and format, and then our engine would interpret each Wesnoth hex as one terrain hex, made up of several unit hexes. Each terrain type would be stored in a file somewhere, with knowledge of its texture and topography, and any additional models that should come with it. For example, we might have ^Fp.terrain for our terrain file, and it would link to flat.topo, forest_floor.tex, and pine_trees.model, using fictitious file extensions. Then Hh^Fp.terrain would be linked to hills.topo, forest_floor.tex, and pine_trees.model. The topo file could be just an array of numbers showing the elevation of each unit hex, or each vertex (i.e. each corner of each unit hex). The engine would also have to know how to put things at an appropriate height based on the elevation.

Sample pine forest hill terrain file:

Code: Select all

* the name it goes by in the map editor
[codename="Hh^Fp"/]
* path to the topography file
[topography] 
    path="../topo/hills1.topo"
    path="../topo/hills2.topo"
[/topography]
* the texture used for the surface
[ground-tex]
   path="../ground/forest_floor.tex"
[/ground-tex]
* choose one model set to use, and use all components thereof
[model-set]
    chance=40%
    path="../models/evergreen.model"
[model-set]
[model-set]
    chance=60%
    path="../models/douglas_fir.model"
    path="../models/larch.model"
[/model-set]
* this terrain counts as both forest and hills, i.e. good for elves, good for dwarves
[terrain-values]
   value="hills"
   value="forest"
[/terrain-values]

Sample muddy creek terrain file:

Code: Select all

[codename="Wwm"/]
* this is the topography of the bottom, not the water itself
[topography] 
    path="../topo/shallow1.topo"
    path="../topo/shallow.topo"
[/topography]
[ground-tex]
    path="../ground/mud.tex"
    path="../ground/rocky_mud.tex"
[/ground-tex]
[water-tex]
    path="../water/muddy_water.tex"
[/water-tex]
[model-set]
    chance=30
    path="../models/cat_tails.model"
[/model-set]
[terrain-values]
   value="shallow water"
[/terrain-values]

Sample not-quite-flat topography file:

Code: Select all

0.0 0.2 -0.1 0.0 0.0 0.5
0.1 0.1 0.0 0.2 -0.2 0.0
0.3 0.2 -0.4 0.0 0.1 -0.2

Come to think of it, I don't know if ^ is allowed in filenames, but I'm sure we can find a way around that by using a different character.

[Darker_Dreams]

Why not do the base terrain (flat, mountain, etc) by just setting values in a terrain generation algorithm. You're going to have to either make complete hex models that fit together or do smoothing at the hex-edges, why not let the rendering program do that work for you?

I'm also guessing you'd want multiple pine trees models, grab a random sampling of them and populate randomly (with a preset range of distances between). When I've played with 3d terrain generation I've noticed there's a huge amount you can make happen "automagically" once you put in some basic work.

[johndh]

Yes, that's all very true, and would get a lot better randomness. For different topography, I suppose we could just feed it a range of heights for each vertex and it would shape the surface accordingly. For example, flat terrains might go between -0.5 and +1, where hills go between +1 to +3, mountains +3 to +5, and impassable +6 to +10, or something along those lines. For trees and whatnot, we'd likely need a way to keep them from overlapping with other terrain features and from obscuring the units, which is why I initially favored preset arrangements, but I'm sure there's a way to do it more procedurally. Just putting them at the vertices might work, since that would keep them out of the way, but also might look rather unnatural.

[Darker_Dreams]

With trees you just limit the density; forest hexes have between 3 and x trees (x being some number we determine to still not be crowded), then based on that we set for each density what the minimum distance between objects is and make sure to leave an opening where no trees can be placed for units to fall into.

My bigger concern is the villages. They'll require large flat surfaces to be created that they'll fit in so they don't looking out of place, and they're single dominant structures that have to share a hex with units.

[Dixie]

I'm by no means a 3d artist, but couldn't you just represent villages by a bunch of tiny houses on the hex? You could have varying styles for varying types of terrains, and a few variants for each style, and have the villages be auto-generated in much the same way you would the forests, providing someone built the tiny base house-models first?

[Darker_Dreams]

it's an idea, though I think the scale issues are going to be much more pronounced if you do that. The other concern is that houses are much more complex to build than trees.

[johndh]

The other concern is that houses are much more complex to build than trees.

Meh. At the scale we're working with so far, it's not hard at all to model a decent house. Texturing would be the hardest part, and that's probably just me because texturing is my weakest point.

I'm by no means a 3d artist, but couldn't you just represent villages by a bunch of tiny houses on the hex? You could have varying styles for varying types of terrains, and a few variants for each style, and have the villages be auto-generated in much the same way you would the forests, providing someone built the tiny base house-models first?

I think keeping them out of the way of the units in the hex would be a big problem, unless we make them really tiny, in which case the scale would be pretty bad like D_D said.

I guess I can give it a shot and see how it looks.