Glyph - Fantasy 4X TBS

Yes, I had the same problems while testing the map; all of them except the black terrain really. However since it is only a demo, I didn't give them much importance; sorry about that. Regarding the lines I mentioned, it's weird that if it's a mesh transparency or texture seam problem; it happens only to those few hexes. If that was the cause, shouldn't more if not all hexes be affected? At least those of the same kind of terrain. Finally about the hex detail and the amount of chunks per sector, it would be great if we could easily choose the amount we want; so we can compare detail levels and easily set them up on the framework.

 

I fixed the getting stuck on the map edges problem, and the problem of the pointer text not showing up.
Both due to last-minute typos that crept in because I was rushing to publish... mea culpa

Oh, and Sam, the circles around the edges are actually supposed to be there, there's a row of covering objects that I intend to use to mark unexplored territory around the outside edges. They don't have to be there, they are just to cover the edge of the map for cosmetic purposes.

I'm not sure about the black textures; I've never seen it before.
I suspect it might be an issue of video RAM running out; what sort of video card do you have?

Nandus:
The water 'seam' is most assuredly not an actual seaming problem, I've verified the meshes meet perfectly, are totally flat, and have normals that all point straight up the world Y axis.
The texture 'seaming' problem is almost certainly an interaction between the surface water layer and the deep water layer.
Since they both share the same shader pass, the only thing that controls which gets put on top is the actual location, as relates to the camera.
As you turn the camera, the depth of a texture that should be under gets put over.
Like I said above, I need to write a tweaked shader for the deep water that forces it to render on Transparency-1, and I also need to write another for the obscuring objects around the edge of the map that renders on Transparency+1.

I might also for the time being just make the deep water an opaque shader. You don't really need to see the bottom of the deep ocean...
The top one needs to be transparent so you can see the difference between regular and deep water, but I suppose it isn't really needed to be able to see deeper.
This will prevent any weird transparency-depth sort problems between the water layers.

 

I have a Radeon HD 7700 with 2GB of video RAM.

 

I don't know what to say; is it happening all the time, or just the one time?

 

Updated webplayer again, with opaque deep water.

 

It happens everytime I have a website running Flash open in another Tab while the webplayer is generating textures and I change tabs. Looks like a Flash / Firefox / Unity Player issue.

 

Ugh... Well, I don't know if I can do anything about that...

Also not understanding why it seems to eat so much memory.

I'm using a two-layer shader, and each map requires three maps: a Main Texture, an alternate layer (this is the trees), and a texture that controls the mixing between the two.
So, each sector needs three 1024x1024 (bare minimum size) maps. Times sixteen equals forty-eight.
Now, even uncompressed, those are only about 4MB each, so it should only need about 200MB of texture RAM.

I've got sixteen maps in that use about 35000 verts each, but from the stats, that doesn't seem to be taxing the system much; it could probably be ten time bigger without much trouble.
There's also two meshes for each sector for the water, but they are simpler, only 1024 verts each.

I guess my next thing to try to attack is to just use a plain, single-texture shader.
The trees won't look quite as nice, but it should cut the needed texture RAM to one third.

 

Hi Tasarran,
Very interesting project ! I have some questions too :

1. How do you create the blending between tiles with different type of terrain (mountain to meadow for example) ?
2. How many triangles have a hexagonal tile ?
3. The hexagonal grid that we can display, you projected it on the terrain with the lighting cookie ?

Thanks and congratulations !

 

1) The terrain blending is sort of a side effect...
Each hex gets an 'airbrush' treatment; I have several functions that basically 'airbrush' around the center of a hex.
I have a function called Splat() that gives a tight grouping, another called Splatter() that is a looser, more scattered pattern, and I have HexSplatter(), which uses multiple smaller Splatters to fill a hex, with a bit of random jostling to make each time more unique.
Tiles that I want to 'fade' into the neighbor get a HexSplatter with a mostly transparent setting.
This makes the edges appear to fade into the surrounding terrain (Mountains)
The Forests are done with HexSplatter with a more opaque setting, this makes the edges harder looking.

2) This mesh is a tri-mesh, but it's not like you think. Instead of the edges of triangles being the edges of hexes, every vertex on the original tri-mesh is the center of a hex. If you know anything about Voronoi/DeLauney patterns, think of each vertex as the center of a Voronoi diagram.
If I need to, I'll elaborate with a picture, but suffice to say, every vertex (on the original mesh) is the center of a hexagon, and the edges of the hexagon are not on mesh edges.

3) Yes, the grid is a Projector; it was the best way to be able to turn it on and off quickly and easily.
The image is only a single hex and the edge of another, so the projector can tile to fit any size map.

 

I would love to see a picture showing this.

Thanks,
Dan

 

OK, here goes:



The mesh vertices are shown in blue, and the hexagons are in red.
Basically, each corner of a hexagon is defined by the average of the vertices of that triangle.

I actually only set these calculations up once, as if the center vertex is 0,0,0; I then have a table of six entries that are the relative coordinates of the corners, and I just add the UV of the hex that I am dealing with at the moment to find the actual point of the corner on the map.

My pointer routine takes advantage of this fact, too.
I just find the closest vertex that a RayCast hit, and that is the center of the hex you are closest to.
Since there are no extra vertices (in the underlying, base mesh that is invisible), there is no extra figuring needed at that point.

 

This thread has gotten so technical, one might forget that we were originally talking about a game; this post is related to the world of Glyph, its races, and their histories...

For many millenia after the creation of the world by Adar, the All-Father, Glyph was watched over by the All-Father and his children, the lesser Gods. For the most part, Glyph was a peaceful world, and life was good...
Until one day, the Gods found the All-Father gone... No trace of him was to be found in the Celestial Palace, and a search of the world as only Gods can perform turned up no trace of the All-Father. What had happened is a mystery; the theories among the Gods were many... The All-Father tired of his existence, and decided to start over as a mortal, or he has gone on to create another world, or he has ascended into realms that the lesser Gods know nothing of...
In any event, after he had been missing for over one hundred years (an eyeblink to a God), it was decided that one of the Gods should take the Father's place at the head of the Celestial Court. But which one? Each of them thought that they were the obvious choice, the favorite of the Father, and the most suited to rule. It was decided that the Gods would play a game, with mortals as their pawns (as the Gods are wont to do), and the victor in this Game of Gods would take the throne.
This 'game' quickly degenerated into all-out war between the Gods and their followers. Bloody war raged across the land for years, great magical disasters were unleashed, continents sank into the ocean depths, and new ones rose... Eventually, Jandor, Lord of Balance achieved the victory, and he assumed the Celestial Throne.

The world began to heal.

You take the role of the leader of a group of mortals, trying to rebuild your people to the former glory of the days before the Godwars.
Will you build an empire to crush your neighbors, or build a thriving multi-cultural nation? Will you strive to become the most powerful wizard in the world, or build a giant trade empire?

The future of your people is in your hands...

This is the backstory as it stands now. I originally thought this game would be set in the Godwars, but I decided it was better to do the game this way, sort of a Civilization-style game where war wasn't necessarily the prime focus.
I'm already thinking of a Glyph 2 'prequel' set in the Godwars era, where truly epic war and magic will be commonplace.

I don't want to get too wall-of-text-y, so I'll save the next post about the races for another time,

 

So let me see if I understand.

You have two meshes.
1) The slick one described above that handles hit detection and the Hex grid. (Simple flat with a max square size of 252 X 252 Hexes to stay under 65K vertex limit)
2) The actual terrain mesh with no colliders. This mesh is actualy a series of meshes stitched together to get around the 65K vertex limit.

"I actually only set these calculations up once, as if the center vertex is 0,0,0; I then have a table of six entries that are the relative coordinates of the corners, and I just add the UV of the hex that I am dealing with at the moment to find the actual point of the corner on the map.
"
You calculated the offset of the six hex corners from the center of the hex and stored them so you don't have to calc them everytime you need them.
If you know the location of the vertex at the center of each hex so you just apply the offsets to get the locations of the corners.
What does UV have to do with any of this?

Thanks,
Dan

 

I like the game backgound.
It gives flavor answers a lot of questions without putting many restrictions on the game at this point.

 

Actually, to get around the (256x256)-2 vertex limit on the underlying low-res mesh (I call this the MoveMesh), I split that mesh up into 32x32 vertex 'Sectors' also.
There is no actual limit on map size now, except for RAM.

So, each 32x32 Sector has:
1) a high-res graphic mesh, which is what you see, and where all the terrain drawing happens. This has no collider.
2) a low-res MoveMesh, with one vertex for each hex. This has a mesh collider. This mesh isn't completely flat; in fact, every point on this mesh is shared in the graphic mesh. This mesh is actually created first, and the graphic one is created by iterating on the MoveMesh
3) two water meshes which are flattened versions of the MoveMesh

It's because the terrain is drawn on with a texture. I can get the actual coordinates (Vector3) of the center of any hex, this will be used for moving.
I can also get the UV associated with that point, and that defines the center of the hex on the TEXTURE... I can then apply one of my hex-drawing functions to that UV, and viola, terrain.

Make sense?

 

Yep. I was trying to figure out why you needed the TEXTURE co-ords until I got to the "hex-drawing functions to that UV, and viola, terrain" and started thinking about Cities, Resources, and other non-mobile stuff you might want to paint directly onto the map texture rather then have as seperate objects.

 

That was some great lore Tasarran. To me it's way better to have multiple paths to victory, beside the obvious conquest of your opponents; it empowers a game greatly IMO. Therefore having the game start after these godswars is indeed the better choice. One question though, is Glyph going to be one whole world(as in CIV) or be composed on a series of different maps(something akin to Majesty, for lack of a better example)?

 

I'm not going to make any illusions that many of these races have not been used in fantasy games many, many times before.
I've never been a fan of the games where they try to make every race an original; I do tend to like me some tropes...
So, call me derivative, I won't deny it.

So, having said that, here's a list of races I plan on having. They fall into three groups, based on sureness of that race being in the final game: Pretty Sure, Maybe, and Who Knows

Pretty Sure:
Dwarves - Warriors Crafters, live in mountains and hills
Elves - Archers and Wizards, live in forests
Halflings - Farmers, tradesmen, sneaky, live in plains and hills
Humans - more than one kind; Wildmen[Barbarians/Vikings], Horse Lords [think Rohan] (more under Maybe)
Just Plain Humans (lol) - of course need a better history, but these are the humans with no advantage or disadvantage, the baseline
Orcs - Live in any environment, live by raiding other races and hunting (see note under Maybe)
Unnamed as yet race of Lizardmen who trace ancestry back to Dragons, at home in swamps
Felar - Cat-people who are at home in the Jungle and are adept at Fire magic
Unnamed Rat-people who live in almost any environment except plains and mountains, skilled at subterfuge and Void magic
Unnamed Insect-People - There are many examples of insect-people in fantasy games, my take on them is that they are a hive-mind, and as such, have no individual fear of death. This will exempt them from any rules affecting Morale and almost all mind-magic. However, it will also make them uncreative, and researching new spells, skills, and techs will be harder for them.

Maybe:
High Men[Human] (never really liked the idea, but these are the preist-y, paladin-y people that seem to recur in fantasy lore. Maybe give them a better history of being a remnant of a powerful church, before the Godwar; maybe these were the church of the (now absent) All-Father)
Goblins - not sure if they need to be a race of their own... Idea - the Orc/Goblin race is really one race, sometimes you have an Orc, sometimes you have a Goblin. Perhaps the diet of an Orc/Goblin as they are raised determines what they grow up to be... Perhaps an Orc/Goblin baby, raised on mostly vegetables/fungi/bugs/etc grows up to be a Goblin. However that same baby raised on meat grows up to be an Orc... And perhaps if you raise an Orc child on something more exotic, you get an Ogre... (Maybe Dragon meat?)
Undead - I want to have undead in the game, of various types, but I'm not sure if I want a race of Undead. If you want your hero to become a necromantic master, and raise an army of undead, you should be able to do that without having a race of Undead.
Bird-people - maybe just flying humanoids, what would be the disadvantage that would make up for flight?

Who Knows:
Unnamed Octopus-people - Amphibious thick-skinned octopus like beings, capable of walking on land or swimming. good at Water magic
Gnomes - 'Tinker Gnomes' Skilled at making amazing devices, needless to say masters of Artifice magic
Other notes - I need some sort of ice race, AoW used 'Frostlings,' which I suppose were intended as a fantasy analogue of Eskimos... Maybe Ice Dwarves? Some sort of more directly 'elemental' creatures?

I know I forgot some, I wanted to just generally throw these out there, rather than quote from the design document, I'll edit if I realize I forgot something major

 

Most games would probably be played in the world-spanning one map game, a-la-Civ/Master of Magic; but I think there should be a campaign/story-mode game where you would play through a series of goal-oriented maps, a-la-Age of Wonders/Majesty.

I also loved the idea that in Master of Magic there was the alternate plane of Myrror, so I will probably try to have at least one, maybe multiple alternate planes.
I also haven't touched at all on the point that I want to be able to have an Underworld, too...

I'll be honest, both the campaign and the alternate realms would be the first place I would look to cut if I need to remove some features... But I love the ideas anyway!

 

Rivers and Roads, too. I can have those drawing in right now, but they'd be ugly and straight.
I'd rather wait until I have my wiggly-line routine looking good.

 

I always have thought that Goblins are the Orc equivalent of a Halflings to a Human, as thus if any balance is wanted/needed between these races; then the Goblins should probably be a different race. However for the sake of artwork alone, not to mention gameplay lore, I can see why it would be better to have them combined in a single faction. If you want to keep adding tropes, High and Dark elves are missing from your list; those are in almost every game. Some choices that could be a little more original, which I understand is not necerarely a good thing for you, are living trees, fish people, blue giants, etc. Nevertheless the list you have come up with is more than enough.

My other suggestion is a theme for the factions should be chosen. For example in Elemental: Fallen Enchantress you have The Kingdoms and The Fallen, which basically is order vs chaos. In LOTR you have the conflict of industry(Sauron and Saruman) vs nature(Rohan/Gondor and Elves). A theme like this can enhance the lore and also bring about gameplay additions. For example maybe the humans + others reject the new order of gods and the violence of the godwars. Thus they are trying to find all weapons/books/devices from that era to destroy them. Another faction may want to bring about the old order of things, maybe supported by the main rival of the god Jandor, and thus wants to find these objects to use them against the new gods. Each faction can have special abilities/bonuses according to the destruction/control of these ancient objects. These objects would then become a main part of the lore and the gameplay, thus enhancing the overall experience significantly.

 

Yes, I did plan to have factions; most of them, but not all, are based around the worship/ideals of one of the Gods.
More than one of them were founded to fight the war, and are not happy that it is over; Jandor and the new status quo have more than one set of enemies.

The objects will be the Glyphs of Power, created by various wizards and Gods during the wars.
One might want to find them to either use them, or to deny their use by another; it is unknown whether they can be destroyed.

I've also had plenty of really bizarre ideas for races, but the problem becomes integrating/balancing them.
For example, lets say I have a purely aquatic race, that builds cities on the bottom of the sea.
They can never win a conquest game because they can't take over more than a coastal city.
Nobody else can really touch them, without the aid of powerful magic; it just doesn't fit well...

I do plan to have a number of 'minor races' that you will be able to enslave/encourage to join/hire... This would be the place for things that are intelligent enough to be troops in an army, but are not one of the 'major' playable races. Things like Trolls, for example.
Or Living Trees, where it might be hard to model mechanics for their obviously very different way of living/building. You just have some of them living over there doing what they do, and you can go get some of them to join your army, if you are able.
They'd basically be groups of indigenous people, 'barbarians' until you come along and teach them 'civilization'.

I think the main source of story conflict here is the echoes of the Godwars.
Technically, it's over, but these things pack a lot of momentum; there's a lot of beings who have devoted their lives to holy war, and now it is... over...
Some beings like that it is over, some want the war to continue, just for the sake of war, and some are unhappy that the God that they backed didn't win.
Some want to restore the old golden days, some want a new vision of the future, some are only out for their own race, or themselves, and some just want to see the world burn...

Which are you, and therefore, which of the others is your enemy?
I think the actual political line will basically break down to Order vs. Chaos, as in preserve the status quo or improve things vs. destroy the world or the new order

 

Having races in another "plane of existence" or whatever you want to call it, can indeed become too troublesome for gameplay design. That's another suggestion I was going to make about the flying race you proposed, in order for it to make sense there should exist something like "flying lands". I've toyed for some time now with an idea for a RPG with races that live underground, undersea, above ground and also in flying islands. So I can understand how something like that can be too difficult to design in a coherent game, not to mention to implement technically.

Maybe if you had a three way system between natural, magical and technological based undersea/land living; then you might be able to balance the races. That way ground races eventually would be able to attack sea races and the other way around as well. It is still too much effort IMO, at least for the current expected results. You probably already played it, but a game that had undersea colonization in it's time was Civilization: Call to Power II. Maybe replaying or playing it for the first time, however the case it may be, might inspire you for a solution to this particular game design problem.

 

Rivers were the bane of my existance for a long time. I came across a solution that worked well for me. http://www.umbrarumregnum.net/articles/creating-rivers
I don't generate the fBM on the fly, I have a large image of it that I randomly select a small selection of it for each river.

I still don't have a way to generate roads that I like yet. I want one that will parallel rivers if it can.

 

I'm planning to use more like the Civ model, where there are roads in a hex or not, and the rivers run on the edges.
So, in a sense, the roads will be easier, as it will just be a matter of drawing some extra lines on top of a hex.
You do lose the ability to move ON the river, though...

I do have actual geometry; I could make the rivers follow the terrain distortions to the sea, but I'd rather have the freedom to make my river go where I want it to go. (with some random variation)

 

This isn't a way to texture the river but rather a way to determine where to draw the river.

You start with a map of the following; The river start point, the river end point, the land / water status of every pixel between them.
You put a fBM image over that to acts as a move cost multiplier to water 0, land 1 and then run A* from the River start point to the River end point using these movement costs. You get a nice random river that looks great.

 

Yes, I got it on second read, and I totally re-wrote my post

My comment above about having actual geometry is because I could use that to generate a height map for the A*...
Food for thought, thanks.

 

Updated the webplayer; now the texture maps are created on my end, and saved.

This cuts the map creation time from 2-5 minutes to about 20 seconds, at the cost of increasing the size of the webplayer file from 14MB to 24MB.

A very fair trade-off, IMO.

 

Map creation went from 6 min to about 5 seconds on my PC. Are the texture maps pre-generated? What did you change?

 

I added a boolean variable called BuildMap, and surrounded all the code that generated the maps inside checks for this var, and also added code that saves the textures to PNGs.
Added code inside a check for this variable being off that loads the textures from the Resources directory.

So, I run the map once with this flag turned on, and it takes several minutes and builds all the maps, and saves them as PNGs.
Then I turn it off and build; the textures get compiled with the rest of the map.

I still do all the mesh creation from scratch each time, but as you can see; that goes really quick.

 

Smart move to have a map cache. This is similar to the approach that Paradox took with the Hearts of Iron series and generally with all the games that use that engine. The map is generated only the first time you run the game, so from that point onwards the data is directly loaded from disk instead of being generated. It's much more efficient in CPU usage terms.

 

It means that if there's a random map generator, it will take a chunk of extra time; but those things are usually pretty slow anyway, so it won't be out of line...

 

Rivers are bound to hex sides, but still have random wiggles...

Milestones still needed before release:

• Roads (will use the same basic drawing code as rivers, so most of the work is already done)
• Minimap
• Map labels (GUI elements that appear and disappear at different zoom levels)

Should be ready for release early in the first week of September.

 

Excellent news! I can't wait to start playing around with all this

 

I like the rivers. I am not 100% sure that is how I want to do mine but this way is growing on me.

I look forword to the roads, mini-map, and map labels.

 

If you want to highlight a single hex, or a list of hexes, would you do it with projectors or any other way? The problem I see with the hexgrid and projectors is that if something is moving between hexes the projector will draw the grid over it.

 

That's not a problem, the projector is set to exclude all other layers except the layer of the graphic meshes, so it won't show on anything you don't want it to.
The real problem with projectors is they interact strangely with lights...
My experiments with a spot light highlight made the projected grid do all sorts of wonky things.

When I plan to highlight a spot on the map, I will have an actual pointer object. Same for pathing, little arrows that point to the next hex.
A light could be used to highlight objects not actually part of the map (units), it would have to be set to exclude the graphic mesh layer.

 

The river code could be changed over to the same way the roads work with only a little tinkering.
I'll leave that to the individual dev, as it would be really problematic for me to set it up both ways.

 

Update: Minimap and map labels in!

Minimap is active; ie, when the mouse is over it, the mousewheel controls zooming on the minimap, and disables it on the regular map, same with keyboard panning.
Clicking on the minimap centers the main camera on the center of the minimap, clicking in the main window centers the minimap on the center of the main camera.

 

I like the mini-map. It has every bit of functionality you could ask for other then Fog of War.

 

Thanks, Sam; I used old-school icons there, but the user can replace with whatever they want.
I currently have twenty terrain types; this is probably overkill for most users.

Those black capsules around the edges are intended to be used to cover undiscovered hexes.
My intent is to modify those into partially transparent gray versions to use for FoW.
Those objects are visible in both the regular map and the minimap.

 

I just tried the webplayer and I've got to say that all new improvements look great. The rivers seem a lot more natural this way that a road based approach, at least as long as they go from each hex middle point to the next. The minimap could be better if it scrolled with the AWSD keys as well, it's quite unintuitive to have it not scroll with main map. I love the new map labels on the map, it's something that adds a lot of immersion, in comparison at a very low cost IMO. The only issue I noticed is some boundries issue with the hexes(at least I believe that's the problem), it might just be the same thing as before; just that now it's outside the "water" areas. Basicaly there is a white line showing up across some hexes, in the forest between the Coldspire Mountains and the Sunrise Sea. Nevertheless these features look great, can't wait to try them myself in the next version of HexTech.



Uploaded with ImageShack.us

 

I know that whoever uses HexTech will want/need to customize it for their own particular needs and tastes, so I only made the minimap the basic functionality that it required.
I thought about making it more detailed when I thought about making the maps zoom to the clicked area, rather than just matching the current centers. I also thought about making it dynamically expand when you moved over it, and relax back to normal size when you left it, but then realized that a lot of people would just scrap those details in favor of their own...

I realized some people might want that map to pan with the main camera, but some will also want the minimap to be an independant thing where they can examine, plan, and just generally browse around. Some might also want it to be locked into the full map (or the known world) at all times, like Civ or an RTS.
So, basic minimap viola...

I noticed that, too, and it's the result of me having < instead of <= in that little snippet of code that draws the forests. It's not drawing the pixels where y=1.0, a simple oversight. It's actually happening across the board, but that's just where the contrast is the most extreme.

A more serious glitch that you might not have noticed involves the rivers...
In your screenshot, look at the hills with the river going around it in the lower right quadrant...
What's happening there is that the river drawing code is correctly drawing off the edge of the texture on top, but when the time comes to draw the next hexagon on the bottom texture, the river gets chopped off when the background of that hex is drawn.
I fixed this by making rivers draw in a separate loop, after all the backgrounds have been done, rather than in each sector after the backgrounds are done.

 

Alrighty; I think this is getting close to wrapping up!

Roads are in now, and the graphic glitches I mentioned in the previous post are gone

Give it a test drive, kick the wheels, and give her a shakedown for final approval.

 

Breaking news... Turns out I was really close to being able to re-create the functionality from HexTech 1.0; here is a screenshot of a map I whipped up real quick from a contour map of Hawaii (the height is exaggerated over 10 times from reality, to simulate a smaller island)

More coming soon.

 

What functionality from HexTech 1.0? I think I am missing something.

 

1.0 was really focussed on the height and elevation type maps.
Everything I've been showing for 2.0 so far focussed on making large-scale maps, like Civilization.

Just wanted to show that 2.0 is more versatile than I've been showing so far.

 

I like the mini-map, how is it created? Is the texture for it dynamicly created?

 

The textures for the minimap are generated at the same time as the textures for the regular map, and stored with them.

It essentially another mesh (like the water) underlying the regular terrain; the main window is set to not show that layer, and the minimap camera is set to only show that layer.

 

Masters of Magic ---> please. Love that game 100%.