Glyph - Fantasy 4X TBS

UPDATE: Webplayer available! www.electricrune.com/Glyph/WebPlayer.html

9/7 - Roads in, minor graphical glitches fixed
Features:

• NEW! Two modes, terrain maps and contour maps
  
• Fully zoomable, 3D terrain
• Base terrain imported from data arrays or a graphic map you create
• Terrain is fractalized for a realistic look to terrain
• 20 terrains as written, infinitely customizable
• Rivers on hex sides, roads through centers
  
• Basic Minimap included
• Works with Unity Free version
  

New screenshots:


9/4 - Minimap and map labels added! Mousewheel and arrows work inside of the Minimap.

8/29 - Rivers added - Hex edge, three different sizes (extensive river system in the forest on the right side of the map)

Glyph will be a turn-based strategy game, set in a fantasy world.

Similar to other titles in the genre, such as Master of Magic and Age of Wonders, the player will control heroes, armies, and cities.
In a plain single- or multi-player game, the goal will be to wipe out your enemies and be the last surviving player.
In the campaign game (which will simply be a series of single-player maps), there might be different victory conditions.

Glyph will have a skill-based training system for regular army units; as part of the unit creation process, entities will be trained with certain skills, the combination of which will enable them to become a certain type of military (or civilian) unit.
For example, you can train a group of recruits with the Spear skill, assign them some spears to use, and they are Spearmen.
Train them in Shield skill, and some sort of Formations skill, and they can become a Phalanx, a special unit that gets defensive bonuses when they are in formation.
This will allow you to upgrade your troops as time goes by, and alter the particular use of a given unit as circumstances change.

Your Heroes will also have skills, including several that only Heroes can learn, not the least of which are the skills in the magical arts.
Magic will come in several schools that will be familiar to any who have played this type of game before:
Light, Void, Air, Fire, Earth, and Water; there will also be a school of Life, which is distinct from the 'white magic' of the Light school, and has a more nature, or druidic nature.
There will also be the school of Artifice, which deals with the creation of magical items, devices, and constructs.
There will be several sub-schools that Heroes can gain access to when they have trained in certain combinations of magic skills.
The plan is to let the player discover these for themselves, but as an example...
Legends tell of wizards with advanced skill in Air and Water that were able to control the weather using spells of vast power.

Unlike most other games of this type, the player will not necessarily start the game in control of a city.
Rather, you will start with a few Heroes, and a group of basic soldiers of your chosen race. You can hire more troops directly from the indigenous population of the area.
Heroes can also perform one more very important function, they are (with the right skills) able to claim Titles, such as Parish Priest, Sheriff, Mayor, etc. These titles will occur in areas when the civilization and population rise to certain levels, and also in response to certain structures being built.
Titles allow a hero that holds them to tax money from the local populace, but also requires that hero to stay in the vicinity, and may require certain activities. (ie. a Sheriff might lose the Title if he repeatedly failed to deal with bandit or monster raids).
Titles allow a political avenue to take over a city, rather than forcing the player to lay siege to an asset that might need to be preserved.

Here are some screen shots of the map in progress. This map is generated on the fly from a couple of arrays, and fractal terrain generation is applied, making for a very realistic terrain, which is fully 3D zoomable. The textures on this working version are lower resolution; the final version will be double or quadruple the resolution on the terrain.

 

I am really into 4x strategies, and I have MoM still on my computer, so I hope this turns out to be great!
Good luck!

 

Wow, the design sounds really complex and makes me want to play.

This definitely sounds like it will be a good game. Keep up the good work

 

I am very interested in your map, how it is generated, and what the game performance is like.

 

I think MoM will always be on any computer I own!
If I am able to achieve half the game MoM was, I'll be ecstatic!

In addition to MoM and Age of Wonders, I do also have to give a lot of credit to the PbEM games that I played over the years: such as Atlantis, Olympia, and Eldritch. The inspiration for the skills system came from those games...

 

Hey, Sammual!

This map is quite different from HexTech; for one thing, in HexTech, each hex was an object. The terrain here is one single mesh.
I have been working on my own take of the HexPlanet, you can find the thread for that here:
http://forum.unity3d.com/threads/137007-Geodesic-globe-WIP

During the process of working on this, I came to realize that if you have a regular mesh with the vertices moved so that they are equidistant (creating a tri-mesh), each vertex can be treated as the center of a hexagon, and you can draw that hexagon by connecting the centers of the six triangles that that vertex is a part of.
This led to experiments in creating a mesh fractalizer; and after some further experiments with the Four-Layer Terrain shader from the Wiki, I came up with something I'm really proud of... (Thanks to Bunny83 on Unity Answers for helping with the function to subdivide faces and keep shared verts shared.)

What you're actually seeing there is two meshes: the mesh that you see (without collider), and another low-res mesh that has no Mesh Renderer, but does have a Mesh Collider. The low-res mesh only has verts at the center of the hexes, and is used for selection.

The size limit you see there is the max size that I can do without having to tweak the code to add another visible mesh. Making the mesh bigger shouldn't be a problem, since the actual calculations are being done on an underlying mesh that has less than 2000 vertices. My calculations say that I should be able to have maps over 250x250 before I start to have to think of another workaround, and that is a really big map...

[EDIT: The actual max size will be any combination of height and width that multiply to 65536 (256 x 256)
So, 128 x 512 is possible, it is also further restricted in that the height and width must each be multiples of 32]

As far as performance, there are no issues. Since it's essentially only two objects, and one is invisible, it is lightning fast.
And since there are not hundreds of Sphere Colliders all over the scene, there's a pretty significant improvement there also.

 

I have been following that thread as well. I have been very interested in just about everything you are doing but my hobby programming time is very limited so I try to keep things stupid simple.

I have 2 maps of 80 X 40 currently and I think they may be a bit large so I want to try shrinking them down to 64 X 32 like Warlock's standard size map.
Have you played Warlock: Master of the Arcane? It is a very good MoM / Civ V / Fantasy Wars mix.

Sounds great!

How are you planning on doing cities and rivers? Roads I can see just projected onto your terrain.

 

I just added some rivers, a city, and roads (in the hex of the city).

I will be posting a webplayer later today, and a YouTube video soon.

 

Great, I can't wait to see them.

 

Warlock is so cool looking it depresses me...

 

I can't decide if I want my game to look like these screenshots of Warlock or Civ V.

 

Played the crap out of MoM and MoM DoG, love that game. Turn limits ruined first one though.

 

MoM is in my top 3 games but I don't know what MoM DoG is.

 

This sound great, any new 4x game is more than welcome IMO; it doesn't hurt that those screens do look great. Any plans on integrating the game with your geodesic globe Tasarran? I would love to have that tech in the HexTech package. Speaking of which, do you plan in ever updating HexTech in anyway? I am currently contemplating on getting the asset and knowing it will be supported in the future would make my decision much easier.

 

Several good questions there!

About the GeoGlobe and Glyph... I have been thinking about having the globe make an appearance as an element in between scenarios in a campaign.
You know, the screen where you either make a choice which area to battle in next, or where you can see the big-picture results of your actions...

About the globe and HexTech; I have been thinking of updating HexTech to 2.0, with this new mesh-map. I'm just not sure if I want to add this on as another way to make a map, or replace the old style with the new... Probably better to leave both in, I suppose; although the new way is quite a bit more efficient in several ways, it does lack a couple of capabilities of the old version.
In any event, Updating HexTech is definitely on my list of things to do Real Soon Now(TM)

About the globe being part of HexTech, I suppose I could do that; but I'll be honest with you guys about some of the problems that cropped up in the globe project...
It really boils down to scale... For even a large-scale game, the maximum hex size is about 50 miles, and this is on the big side...
This is a globe with 500 hexes around the equator, and 100,002 hexes. This is one very big map, bigger than I think is really playable.
Take the hex size up to 100 miles, you have an equator of 250, and 8672 hexes.

Now, if you want to make more detailed maps of your hexes, that's how many you need...
It becomes a problem pretty quick... I think that the sheer amount of data you need to represent on a full-sized globe is just too unwieldy for a game.
It will end up being like one of those huge board games that people love, but never get to play because it takes two hours to set up, and all day to play.

Take a look at the .2 version of the globe:
http://www.electricrune.com/Worlds/Worlds.html
Set it to 100 subdivisions (the 50 miles/hex setting), and draw the hexes. You'll see how staggeringly dense the hex grid is.
IMO, this might be too much data for most users to process.

Thoughts?

 

Having the globe used to show the progress of the campaign in between missions seems like a great way of using the tech, while immersing the player on the game. I remember the first time I saw this, in Dune 2 I think, and it was a great way of seeing your overall progress of conquest. Way better than words at least.

I love your ideas about updating HexTech, I was basically hoping that was the case; so I am getting the package like tonight to support this. I have 2 games on my mind that I want to make and one of them would be done much better in a geodesic globe, than in a plain flat map; but in any case I can start working on either of them.

Regarding the scale, I personally have been testing a 125 miles(200 km) hex size; with a total of 200 hexes around the equator. I believe such a set up would be playable for any kind of grand strategy player, it certainly isn't that much larger than a Victoria 2 map for example. The only difference is that since all divisions are equal, sea divisions are much more numerous in this approach and that can be kind of an inconsequential waste. The only real question is how to optimize everything to support such a large map.

To sum up, it really depends on the exact scale the genre requires; IMO a grand strategy game such as Victoria or HOI would work perfectly with the numbers we are mentioning. If we are talking about something different, like a game similar to Unity of Command(easter front wargame); a much smaller number of hexes(but bigger in actual size) is enough. In any case and IMO, the tech should be flexible so it can support extreme scales; so as to allow different approaches and genres to be implemented, regardless of the eventual game design mechanics behind them.

 

Ugh, I'm just going to ignore this awesomeness ... a couple game ideas come to mind ... must focus on current project !

 

About the game scale, you can work around a large scale by increasing the time represented by each turn...

If you have 125 mile hexes, and you want the average move to be something like four hexes, that's 500 miles.
If you're talking about something like a ship or train, that can travel non-stop, then one day per turn will do this...
This requires about 20mph non-stop.
If you're talking about men on foot, 500 miles would be a very long trip; 20 miles per day is a decent average for fit troops, and that would take 25 days, with no days off.
So, if your game is focused around infantry-type units, one month per turn would get you a game where your units can move 3-4 hexes per turn...

Or you could just do what Civ does, and make each turn way longer than you'd really need to do anything... Minimum increment there is one year, and it's usually many years through the early part of the game.

Then there's of course the pure abstract time model; one turn is one turn, and it doesn't matter what time it really represents.

 

I'm still thinking about what I'm going to do on the Asset Store. but my current thought is:
1) to add the mesh-type maps to HexTech
2) offer the globe as a separate offering

My thinking is that anyone developing a map might want to use either the mesh-map, or the tile-map; and they might want to use both.

However, I'm not sure there is as much overlap with the globe... I think it will probably go unused by many people, and it really should be a separate thing.

Both things need some more work before they are ready for prime-time; I will pause work on Glyph for a week or two and make my Asset Store products a priority.

I also want to upgrade the way the globe currently works by adding the mesh-selection via raycast to the GeoGlobe system.
Right now, the globe works by adding a ton of Sphere Colliders at the nodes of the mesh, and this creation process is very slow.
My work on the flat map has shown me how I can get around this and find the vertices directly from the mouse position; which should increase the performance and useability of the globe significantly.

 

http://www.gamespot.com/master-of-monsters-disciples-of-gaia/

 

The MoM I was referring to was Master of Magic...

http://en.wikipedia.org/wiki/Master_of_Magic

I was going to say that Monsters looks like it was heavily influenced by Magic...
However, it looks like MoMonsters actually pre-dates MoMagic by three years!



In any event, it looks like anyone who liked one of them would like the other, and they would also like what I have in mind with Glyph!

 

In my case the units would be based around actual vehicles and infantry units, then the distances they can travel and the hexes size actually matters; thus a CIV abstract system is really not preferable at all.

Moreover I was thinking on going on a quasi real time concept, in which although each turn is indivisible; you can only alter the speed at which they pass. It's something I've loved in my strategy gaming, as far back as 1998s Pax Imperia: Eminent Domain.

Specifically I am thinking on one day "turn" increments, with the mentioned 200km(125 miles) hex size, to model real life warfare in the twentieth century. IMO this should work quite well, specially if based on a geodesic globe with all of HexTechs' features.

 

I think that's a great plan. The update to HexTech is more than welcomed and it can only generate good publicity for your release of the Geodesic Globe asset. The tech certainly merits its own asset in the store, plus the derived additional income for the creator.

However I have to disagree on your appreciation of its potential; if both techs are integrated, so as to make the geodesic design as easy as one based on a flat map, I can't believe it won't be popular with the developing community and thus part of many great games.

The upgrades you mention certainly merit some extra tunning time before release, since we will certainly appreciate them more the sooner they are introduced; but in any case you can be sure that, baring any unforeseen events, you have your first customer for this new asset right here

 

As far as scale goes I use a base hex size of 6 miles wide for a number of reasons. (See link for some of them) http://steamtunnel.blogspot.com/2009/12/in-praise-of-6-mile-hex.html

For my MoM like game I don't yet have the scale pinned down, the following are the hex sizes I am considering.
6 Mile
24 Mile (X4)
48 Mile (X8)
72 Mile (X12)
144 Mile (X24)

I am going with the 'pure abstract time model' of 1 turn = 1 turn.

 

I downloaded Master of magic recently, About to check it out when I get the time.

 

This sounds very much like what I was thinking of for Glyph...
One day turn increments, but you wouldn't necessarily have to play through every day.
You might send a unit out to a nearby hex, and it will take them ten days to get there.
Unless something happens to interrupt it, those ten turns could just happen, and seem like one turn from the players' perspective...

 

Is that some kind of auto-turn actions? Because if the ten turns seem like one "turn" to the player, then the unit moved automatically through all those ten turns in one go. And the thing is that, as I understand the system, if any other unit requires an order in between those 10 turns(maybe because they encountered the enemy); that illusion is broken, since the player would have to act on those 10 turns.

I believe the system you mention works only if no other unit, in those 10 turns, requires any kind of input from the player. It would be something very similar to the first few turns on any civ game, where all you have is your first unit and city. During that early steps, you pretty much only move your unit around, because the first tech and buildings take like 10 turns at the very least. So if you give movement orders that require more than 1 turn, they might appear similar to what we are talking about.

 

Looks great

What platforms are you going to support?

 

Main target is PC; I am thinking of maybe having an ongoing web-based persistent-world server with a set rate of time...

One possibility is to have this web-based game free-to-play, and use it as promotion for the pay version.

This way, people could play the 'demo' without even having to download anything...

 

Other then the Unity plugin (Unless you publish to flash).

 

LOL, if you don't already have the Unity plugin installed, you're no friend of mine!

 

Some of us can't install the plugin at work (Stupid corperate rules).

 

Sadly this is the case for me as well. In fact almost all game related web sites are blocked where I work, but web sites I can get around; the real problem is the web player.

 

It might work in Flash; I'm not sure about the limitations.

 

Any updates on this project?

 

Sorry to make you ask for it!

I've been working on two things over the last couple of weeks: getting the engine to work with bigger maps, and procedural terrain painting (the screenshots above actually had manually painted maps).

I have the terrain painting working great, but it is slow. It will probably end up having to be generated editor-side, unless you want to deal with a five-minute map creation every load... Any ideas anyone might have for faster drawing to textures would be helpful.
I do have an avenue to pursue about this, swapping SetPixel() for SetPixels(), but that can wait until the issue I mention below. (call it Action Item B)

I have my test map working with a two section by two section (64x64) map.
The terrain drawing works seamlessly across the seams, but I need to tweak the normals around the edges, they show up when the terrain is bumpy on the seam. A minor cosmetic issue that I'm sure I will be able to fix. (Action Item C)
The code that creates the segmented maps is hard-coded to work with a 64x64 map at the moment; I am working on making a universal function, and that will be the final hurdle toward being able to support any map size up to 256x256 (or 512x128, or any combination that Height*Width <= 65536).
This is currently Action Item A.

The map is created from the same sort of graphic map that I used in v1.0, but after the base height mesh is created, the terrain is fractally modified, and as I mentioned above, the terrain is painted procedurally.
You will be able to provide a map of any size, and the engine will figure out how many sub maps it needs to create and take care of all the rest.
The only restrictions will be the max size, and height and width must each be a multiple of 32, but they don't have to be the same size.

There is also a grid that can be turned on and off instantly. Been playing around with different settings for that, I think white lines 40% transparent looks good, but that will of course be able to be modified by devs.

I will release a webplayer as soon as I can show off a map that is 256x256.
If there's a lot of feedback begging for a peek, I'll consider putting out a player of what I have at the moment this weekend.

 

I am interested in seeing what you are doing but I am so busy right now that waiting for a bit will not kill me.
As for speeding up your Texture drawing, can you detail exactly what you are doing? Without more information I couldn't even hazzard a guess.

Thanks,
Dan

 

Right now, I'm basically using an airbrush-like technique by generating a random circular offset and using SetPixel() to draw the appropriate color onto the texture maps. Doing this multiple times with partially transparent pixels makes a decent fuzzy blob. Some hexes can take up to two thousand pixels.

I think I can speed it up by copying the working area of the map into an Array of Colors, working mathematical operations on that Array, and using SetPixels() to copy that whole Array back to the map.
I've read on the Answers site that can be up to 15x faster, but maybe there's another, even faster way.

 

Action Item A is complete; sort of... It works for every size except the utter maximum size.
Small hitch in the plans... I knew the limit on vertices wasn't really a round 65000, I had assumed it was 256x256 (65536).
It turns out that the actual limit is two bytes short of that, at 65534.
Since I was basing my maps off of a main 'move mesh' that has one vertex for each hex, but it now looks like I will have to split the underlying move mesh in order to support bigger maps. This is a semi-minor setback, I can modify the code that I make the graphic segments with...

However, it does open up a further possibility to make the map even larger.
I'm not sure what the maximum size will be, but after I make this change, it will probably be limited only by available memory.

On a related note, I realized how to easily fix the seam normals issue I was having, so scratch Action Item C above...

 

Fantastic! So with A solved for everything < 256 X 256, C solved, and an action plan that will speed up B by an order of magnitude I am guessing we will see a webplayer example soon?

 

I just need to get the painting converted over to the new scheme, then I will release a webplayer.
All the routines are written, I just need to adapt them over to the universal scheme.

I have a 128x128 map already made, and a 256x128 almost complete.

But I think I will try to finish the map of Westeros that I have been working on...
160x384, scale approximately 10 miles per hex, total of 61,440 hexes.

Any Song of Ice and Fire fans?

[edit: map picture deleted for being too long]

 

Cooool : D

 

Awesome developments Tasarran! Congratulations on shortening that action list and so fast at that. Maps so big they are only limited by available memory are more than welcome, although I think a game world so big is only manageable for grand scale strategy games; anything with that size is very difficult to control in other genres.

So much cool stuff is making me, and assume most of us in this thread, wish for a web player to placate our hunger for hexes. It would be great to have one for the next update Changing the subject, do you have any news on your geodesic globe? That's another project I am deeply interested in.

 

Not a Song of Ice and Fire fan but it will be very interesting to see how this map looks in your system.

 

The GeoGlobe hasn't made any direct progress while I've been working on the map, but what I'm figuring out here about multiple maps will be able to be applied to the GeoGlobe.

So, in a sense, progress is being made on the globe, indirectly.

I promise a webplayer coming Real Soon Now (TM)...

 

OK, I posted this just for those of you who are dying to see the demo...

www.electricrune.com/Glyph/WebPlayer.html

The draw routine is still the slow mode; I haven't re-worked this for speed.
Each texture takes 20-30 seconds to create, so have patience; this map is 128x128, or 16 maps.
It does show progress, so it won't be a completely boring wait.

In the future, two things will be done to speed this up: the draw routine will be speeded up by using SetPixels() rather than directly drawing each pixel using SetPixel(); and I'm looking toward doing something to make the map processing offline.

In any event, have patience, and enjoy!
I put a pointer routine in that shows the coordinates and terrain type under the cursor.
Use mouse wheel to zoom, right mouse to tumble the camera, WASD/arrows to slide the camera.

Let me know what you think; I'm needy!

 

I am checking out the webplayer right now. I am experiencing some oddities. The map edges have circles cut out of them that cover some of the edge hexes, once you slide the camera all the way to one edge of the map it gets stuck on that side of the map and if you go to a corner you get stuck there. When I re-loaded the page to get a better look at the textures and mesh half way through the generating textures all the non-water textures went black and stayed that way. I also can't see the UI overlay that your screenshots have that shows the coordinates and terrain type under the cursor.

 

Thanks a lot for the update Tasarran, that was an awesome webplayer! I thought the map would take a long time to set up, but in my case it wasn't more than a minute or maybe two; totally acceptable IMO. But of course the faster it gets generated, the better it will be. I loved the detail of the active volcanoes on the main island, that was a really nice touch. However close to it there is what I think is a bug in the hexes joints, there are some lines there which shouldn't be showing; I've attached an image for reference.



Uploaded with ImageShack.us

With or without the grid, the lines keep showing up from that angle; if you rotate the camera they disappear however. Finally I was wondering if the texture detail can be increased for the tiles, because on smaller scale games, it may be a good idea to increase the zoom level and thus a detailed map for tiles is desired. Thanks again for the update Tasarran and keep up the good work!

 

The apparent seaming there is something to do with the transparent meshes that make up the water, and the way Unity figures which object is in front of the other. You can see that seaming appear and disappear as you rotate the camera, and which mesh is 'in front' changes.

I say 'apparent', because those objects meet perfectly at identical points, and the normals are all flat.
At the worst, there might be some minor texture-seaming, only because I didn't try to make a texture for that that was seamless (yet).

If you look closely, you can see something similar going on with the obscuring objects around the edge... Sometimes the renderer puts the water in front, sometimes the Hidden Hex Object.
It's strangeness with the way transparent objects operate...

I think both of these can be fixed with some minorly tweaked custom shaders that re-order the transparent objects in the scene into more discrete layers.

Also, about the texture resolution... It can surely be increased, at a cost of 4X preparation time.
This was intended as the bare minimum, to make development faster.
But if I was going to increase the overall resolution, I'd split the sectors into 16x16 chunks (instead of 32x32 chunks), and increase the detail of the mesh.
This would have the side effect of doubling the texture resolution, because the same texture would cover half the space.

 

I noticed the bug with the map getting stuck in the corner, I must have <'ed when I should have >'ed...
I won't be able to fix that until tomorrow night, so try not to slide too far, sorry!

Has anyone else had the other problems Sam mentions above?