Ziggurats!

So, firstly, an announcement – URR 0.3.0 is going to include some dungeons (“dungeons” meaning tombs, temples, ziggurats, dungeons, etc etc). It will expand development time by a bit, but I think we need to get some gameplay moving. I decided that as important as the history generation aspects are in the long term, I want to get some gameplay moving at the same time. The dungeons won’t include murals, or sculptures, or traps (probably) or bosses, but I’m aiming to at least work on the first stages of some dungeon generation algorithms, as well as creating their exteriors. For whatever reason (perhaps because I thought it would be a comparatively simple structure), I decided to start with ziggurats.

These will be one of the major classes of building you’ll find in tropical areas. Some will have been built by still-existing civilizations, whilst others may be rather more ancient. It is possible I will allow for the rare ziggurat to exist in desert regions as well (think Mesopotamia, etc) but they’re primarily/exclusively going to be tropical. I’m still working on the mechanics of building interiors, but I decided to take a break from history generation for a bit and start working on some actual gameplay.

Early research found a ziggurat look that really appealed to me.

Currents

What I really liked was this sense of the ziggurat emerging from the jungle; as something that was hidden and overgrown, and could be easily missed, or that blended (relatively) seemlessly into its surroundings. However, the more I looked, the more I realized this look was generated by trees (and their canopies) – which is to say, things that go vertically upwards from the ground. The key question was how to emulate this emerging-from-the-jungle look whilst keeping a top-down view. Trees would not work in URR as they give vertical blending, but no horizontal blending. Ultimately, I needed something that could blend horizontally. The obvious solution was creepers and vines. I’d been thinking about unique things I could add to various climates and biomes anyway, so it seemed to me that vines could be added to all tropical areas (which I’ve now done).

Vines are mostly for decoration – in gameplay they may slow you down a little (which is to say, turns passing them might take a few more ‘ticks’ in-game), and when I start working on combat, there may be context-sensitive possibilities to trip over them, etc. They spread across the ground in tropical areas, and serve as the main way to blend ziggurats into the surroundings. Ziggurats are not quite a finished product yet – I need to add doors which lead to the interiors (which are actually being worked on now), and create a system to ensure the interiors have enough floors, each of the correct size, to make the interior match the exterior. I’m also going to add ramps to some ziggurats, probably based on civilization preferences. Lastly, various things will be atop ziggurats – shrines, sacrificial altars, etc etc. Nevertheless, here’s your first ever glimpse of a building, and as ever, click to view full:

Z_Teaser1

You may also have noticed a new character amongst the general grass characters. This is the character for a plant or fungus, which I’ve now added in, and will probably be the subject of a blog entry in their own right another time. They will not have gameplay effects in 0.3.0, but I’ve included them here to further aid the detail in each biome. Meanwhile, interiors are being worked on, along with further history generation, though the latter has been slowed a little by a strange theocracy bug I’m struggling to eradicate. A huge variety of gods can now be generated too, and family timelines are coming along nicely. Chance are next fortnight’s entry will be back to history gen, though it might be interiors, or plants, or really anything else. There’s a lot in development!

Last but not least, I did an interview for a new games blog, The Game Bastion, about URR, goals, the future, etc. You can read it here:

https://thegamebastion.wordpress.com/2013/02/03/interview-with-mark-johnson-of-ultima-ratio-regum/

Map, Progress Update, and Calendars

Three things to cover this week. Firstly, thank you all for commenting on the world map, either here or on any of the fora or websites the game can be found on. It roughly came to 50/50 in favor of each of the two maps, and in light of my own thoughts about adding other kinds of map, I have decided on the following solution. For the terrain map, the existing colour-on-black will be kept, but with all the shading and detail described underneath the picture below. However, background color mapping will be used for a climate/rainfall/temperature map, which may or may not appear for the next release – quite a few people said that kind of map looked sensible for displaying temperature or similar, and I think that could work very nicely. Without further ado, here’s how it currently looks:

A number of things have been done to the map. Firstly, light/dark shading is a gradient based on the height of that square, and the height of the surrounding squares. Secondly, colour shading between biomes is now present so they fully blend into each other (the description of a blended tile will still tell you whether it is taiga or temperate, for instance, if you are concerned by such exactness). Thirdly, coastlines are now present, and vary in shade. Fourthly, shallower sections of ocean are now present, though these may be changed in more detail when we get to the stage of adding naval mechanics. Fifthly, mountains are now slightly tinted according to the biome they’re in, and are also shaded according to their size – 3×3 mountains are light, 2×2 mountains are a mid colour, whilst single-square mountains are darkest. Volcanoes, both active and dormant, have also gained new colour schemes, as have rivers! The world map is not fully finished – I intend to add seasonal ice and glaciers in the future, as well as a marsh/swampland biome and some very rare regions (think geysers, or canyons, or salt deserts, or plateaus, etc), but that will come in the future; for the time being, I think the appearance of the world map has been brought in-line with the graphical quality I’m aiming for from the rest of the game (especially the two secret feature-bloats).

Secondly, a general progress update. I’m now spending most of my time at the moment programming for 0.2.0, and as you can see, the objectives on the Development Page are being covered at a steady pace. Redoing combat mechanics has been removed from this release – I have come to realize there is little point in doing so until all the civilization/NPC spawning/de-spawning mechanics exist, and those cannot exist until histories are generated and civilizations start to appear. Thus, the world of 0.2.0 will be devoid of anyone else bar you – I moved onto combat much too rapidly last time without having the background or the basis for it built, and I’m not going to do that again. I intend to redo how weapons and armor are managed this time, and how you view them, but you won’t have anyone to fight. There will be a ton to see this release, but sadly nobody to stab in the face. In the mean time, saving/loading games is 80% complete; skill trees are roughly 80% too; world generation and character generation have been separated; you can browse saved worlds and saved characters; seasons and time of day play an effect, and you have a little quasi-sun-dial thing on the sidebar to tell you the time; and the longest-standing bug (memory leakage on the travel screen) has been fixed.

Thirdly, just a little bit about calendars. Currently the game uses our Gregorian Calendar, with each month with the appropriate number of days and seasons distributed as expected (though there are no leap years). However, in the future (meaning 1.0.0, the release after this one), I think I shall allow each civilization to create its own calendar model, and if you are in a civilization you will use that calendar model. If you are not, then it will likely default to that of the civilization you were born in, or you can simply choose from existing calendar models. I’d like to have calendars ranging from ours, to ones like the Mayan calendar, to any other kind of model I can dream of. I think that would be quite a neat addition, and one that might be essential for solving puzzles and things when exploring tombs…

LASTLY, time management is also being redone – there are indeed 1440 minutes in each day, and each of these will consist of a number of “turns”, but the basic turn is not that of the player. “One turn” is the length of time it takes for a part of an explosion to explode, say, or for an arrow to fly two squares; by contrast, the player will only “get a turn” every ten or twenty turns, and different player actions will take difference lengths of time. This enables me to allow for a large number of rapid actions (picking up, dropping, etc), and for foes with speeds of 1, or 1.2 or 1.6, to vary their turns appropriately (which will be particularly important when mounted warfare appears). This turn system is an entirely under-the-hood thing, but I’ve been working on it quite a bit, so I thought it merited a mention.

And now that’s a lot of words, so I’ll call it a day there. Let me know what you think of all the latest developments – I’ll be aiming for a similar post next week, though I may also post about the ‘Rule’ skill tree instead, as that has a lot to say about the future direction of the game in some areas.

 

Map Colouring

I had another blog entry planned and all but written today about the ‘Rule’ tree, but that’s going to be posted next week in light of last night’s work. I’ve been doing some upgrading of the visual appearance of the world map – it was looking rather monotonous, so I decided to add a coastline effect, some shading for height levels, and variation in the icon and coloring used to display land. I’m very happy with the coastline effect, though the height shading is VERY unsubtle at this point, with broad-brush gradients and no real mixing between terrain shades (which I intend to add today or tomorrow), but in principle, that’s a big change I’m moving for. So do please note this is in its very early stages, but here’s what things look like now (map size = small):

However, I then (entirely accidentally) switched the land coloring to be inverted, and got:

I rather like it. It certainly shows up the height shading much more clearly, even in the very basic form that shading currently takes. Rivers look a bit odd, and should probably have their colour changed, but I thought this was interesting enough to be worth posting about. Which does everyone prefer? Note that both are going to gain a lot more detail and subtlety in terms of shading of terrain – different types will blur into each other – and in terms of shading of height, as you can currently very clearly make out the height changes. However, with all that said – which looks better? I’m still undecided myself, so I’d like to open this up to some discussion.

Faux 3D

I had a request some time ago for a blog entry dealing with programming in a z-level to a top-down, 2D game. It’s been delayed by several weeks due to working on the release, and now it’s been delayed by a day because I spent almost all of Monday on academic work. Now, however, I’ve managed to find a moment between editing chapters to put something about this up.

URR does not use cubes. Which is to say, a hypothetical map with a top height of 10, with some sky and some ground, does not look like the thing on the left, with cubes of each substance stacked upon each other, Minecraft style. I obviously considered doing this, but then realized I was using up an unnecessary amount of memory if I did it that way. This isn’t a construction game, and this isn’t one where you can dig. Those are the two fundamental reasons why cubes of terrain are simply unneeded, and inefficient.

Instead, URR actually only has one cube of terrain in each x/y coordinate square, regardless of the height of that square. So, square [0][0] might have a ‘z’ value of 1, square [0][1] might have a ‘z’ value of 2, and so on. Each square has its own z value. Squares then have a ‘true z’ value, which reflects if something has been ‘built’ on them, for instance a tree, or a wall, or whatever. These are almost exclusively things you cannot see through.

Thus, when then generating the field of view each turn, the game ignores any squares that are blocked and on your level – for instance, by a tree – or any square with a true z level greater than that of your head (the player is two levels high, as are all humans). Monsters, in turn, cannot see creatures with the same requirements, and like you can climb or not up areas of various z levels depending on their height.

But, I hear you cry – what if you have a wall on a square, and the square’s z level is 10, and the wall is 5 squares high, so that square has a true z of 15. If the wall is destroyed, giving that the true z is the important value, surely the true z is still 15? When a structure is destroyed, the game recalculates what the true z of that square should be according to the height of the thing on the square, and then sets it.

But, I hear you cry (again) – what if you have a BUILDING, with multiple floors? What if you have a tower with sixteen different floors in, but the square can only store one z level? Well, buildings – although in their very early stages – are simply loaded separately. There is still fluid movement between buildings – there’s no load screen, things can go in/out of buildings at will, and for gameplay purposes, there will be (once buildings are fully implemented) no gameplay difference between a building here and a building in, say, Dwarf Fortress. The data is simply stored differently. While splitting ‘land’ and ‘interiors’ up has provided extra work in the short term, I deemed the massive reduction in required storage and the massive increase in game speed that game with it to be more than worth it.

And with that, our next update will be in a fortnight, when I will unveil a skill tree. Excitement!

Cartography

It’s been a while since we had some screenshots, and as most of the pre-0.1.0 work is under the hood stuff on glitches, saving and loading and optimizing generation and things like that, I thought I’d stick up a few world maps. These have been created using a variety of different settings, all of which are enabled for 0.1.0. As ever, click to see full-size. For instance, we have a map on an ‘average’ sized map (yes, you can now change world sizes!) with high tectonic activity, high landmasses, and a ‘continents’-style layout:

Or an ‘ice age’ pangaea-style map, with a single large landmass and a much colder climate (and a ‘massive’ sized map):

Or perhaps a tropical chain of islands, at the other extreme:

Or a ‘small’-sized map with lots of forests and rivers:

And the heightmap of the same:

Or, for that matter, anything else. So many little things have been done in the past few days I haven’t been keeping a list, but everything is just getting smoother. Tomorrow I aim to blitz all the pathfinding and motion for large creatures (currently just dragons at 3×3 for 0.1.0), then one more day of fiddling with the final many bugs/glitches/remaining issues, then I’m going to try compiling and testing that version on the 5th. Stay tuned!