next »

[Ultima Ratio Regum]

Lots of trap progress coming along. Clouds of flame, poison gas and smoke now generate, drift, dissipate, and register when the player enters/leaves them, but apart from smoke (which blocks your LOS), the other mechanics aren't yet implemented. Also working on some of the trap graphics:

[jO]

"Trap smoke. Don't breathe this!" (WIP)



Made huge progress with traps - will be posting some screenshots of them in action soon!

oh man, it's hard to describe how much I love the visual aesthetics of your game.

[Ultima Ratio Regum]

oh man, it's hard to describe how much I love the visual aesthetics of your game.

My thanks  . I'm hoping to stress to the player a lot of the game's aesthetics are found by looking at objects, not to mention a lot of important information on the look-up pages...

[Ultima Ratio Regum]

The most requested item to date for URR is now implemented!

[Ultima Ratio Regum]

MEANWHILE, this week's update, the second detailing how the puzzles/riddles generate:

Where we left off last time we had a series of clue planned. For a 2×2 puzzle, for example, the first clue might need to be “Top-Left is west of Top-Right and north of Bottom-Left”, and the second is “Bottom Right is next to Bottom-Left”. To do this, the game then finds a synonym for each clue component, all of which have a variety of synonyms. For example, a lizard can be referred to as a “reptile”, “sticky footed one”, “cold blooded one”, “scaly one”, “one who regrows tails” or “tree climbing reptile”, whilst a skull may be a “dead one”, “cranium”, “one of bone”, “memento mori”, “reminder of mortality” or “deathly visage”. One is chosen at random each time a particular block is in a puzzle, with plurals added appropriately.

An earlier release had a number of different ambiguous clues. One was “the reptile” – this could be a snake or a lizard. If only one of the blocks had generated that would be fine, but there was always the risk that both would generate and therefore the solution would be ambiguous until you’d tested both, at which point the player would know from that point on which was correct and which was false. A few people actually suggested to me that ambiguity of this sort was acceptable – the player needs to figure out the identities of vague clues – but this is a very bad idea. It fails to meet the three design goals I mentioned in the first part of this series, and given that some puzzles will be associated with traps in the coming version 0.4, I cannot allow any trial-and-error where’s something to stake.

It reminds me of the idea of “Guess what the teacher’s thinking”. Imagine a teacher says “Name a classical composer”. You say “Beethoven”, and the teacher says “Wrong! The answer was Mozart”. You did answer the question, but the question wasn’t worded well enough to make clear to you the range (or narrowness) of the expected responses. It question implied there were many possible answers, but since there was actually only one, a less stupid question would have been “Name a classical composer born in 1756″. This would be the same issue – the “lizard” clue could mean either, but only one will be accepted by the game. Another example of this was the “shadowed moon”. This was meant to be the eclipse, but it could be interpreted as being eclipse, crescent, half or even gibbous moon. Much too unclear. Another clue that I never realized was vague came to my attention in a very unusual way which I think says something interesting about the different ways people “read” games.

This is a young boar (this is also the only blog entry which will have such endearing pictures). It has stripes. One of the clues for a boar was something like “the one with the young stripes”. I realized most people might not instantly know this, but with a little bit of research, or a process of elimination, should have made this clear. However, consider the three variations of the boar block – two of them have things akin to “stripes”.

One player suggested they found the clue confusing because one of the boar designs didn’t have stripes, and this made them wonder if the variations of image on blocks had some impact on the clues. Nothing like this even remotely occurred to me before release, but it made me realize (not for the first time) that others will “read” a game differently to you, especially if you’re the designer and have been staring at the game for a long time. I therefore removed this clue because it raised a little confusion about the relationship between the clue and the particular variation of the block.

Similarly, for those who follow the blog you may know of the endless confusion and debate over how to work one particular clue. “West of” is fairly self-explanatory, but there are a large number of clues that state one block is “opposite” another. This is meant to refer to a block that is orthogonal and as-close-as-possible to another block. For example, if you have a 2×2 clue, then the bottom-right could be “opposite” the bottom-left or top-right, but not the top-left. The lower-level clues were designed to build up an understanding of what exactly this term means that could then be applied to the higher-level challenges. This went through a number of different iterations. I tried “next to”, but that meant that if there was a gap between two pressure pads – even if orthogonally adjacent – some players were confused about whether this classed as “next to”. I also tried “adjacent to” but some players thought this meant only left-right, not up-down. “Touching” was equally unclear, whilst “proximate to” was vague and could include diagonals, conceivably. I don’t know if “opposite” is ideal, but it’s certainly less ambiguous than a bunch of the other options – it implies there are no other blocks in between A and B, and that it can be vertical as well as horizontal. This was another example where both my “reading” of the game differed from that of others (I thought “next to” was fine, at first), and that clues need to remain cryptic, “in character”, without being unclear. Of course, every clue could say “A is either left, right, up or down from B, without a block in the middle, and potentially with a blank tile in the middle”… but somehow that just doesn’t have the same ring to it.

[gimymblert]

One rules of thumb I tend to use is that ANY variations/changes is an information when designing, and that structure (relation meaning in the context of the game) has to be explicitly introduce before being part of a puzzle, ie "adjacent" concept in the game realm would have been presented in a safe spot before any puzzle.

The things is that game is made of convention and abstraction, because abstraction boundaries is ambiguous in some way (how much it is like real life?), we need to enforce proper "telling" before any interaction/challenge, either explicitly (tutorial) or implicitly (priming) and anything in between.

[Games Inquirer]

Maybe the young boar could be missing the big teeth

[Ultima Ratio Regum]

One rules of thumb I tend to use is that ANY variations/changes is an information when designing, and that structure (relation meaning in the context of the game) has to be explicitly introduce before being part of a puzzle, ie "adjacent" concept in the game realm would have been presented in a safe spot before any puzzle.

The things is that game is made of convention and abstraction, because abstraction boundaries is ambiguous in some way (how much it is like real life?), we need to enforce proper "telling" before any interaction/challenge, either explicitly (tutorial) or implicitly (priming) and anything in between.

I generally agree, which is why I tried to set up the basic puzzles; at the same time, I have to prefer a show (rather than tell) approach, which is why I have specifically not been explicit anywhere. Even though there is a guidebook section on puzzles, it's going to be more like hints and tips that actually explicitly defining each term. I always likes games where incomplete information is even and the player needs to experiment to codify the rules properly.

But as you correctly say, it's the abstraction thing and the importance of establishing the rules in that abstraction. However, I think there's also a risk that too much telling not just leads to a removal of discovery and the satisfaction of working things out, but if you make procedural generation too... what's the word... too "smooth", let's say, and cut out any possibility of you reaching a tricky puzzle before you've got all the data down, I think that removes a lot of challenge. Which is to say, if you were to hamstring the generation algorithms to ensure every ziggurat, no matter where you started, got a nice, friendly progression of puzzles (rather than, say, the Out-of-Depth monsters in Dungeon Crawl), I think that level of "safety" would remove a lot of the interest procedural generation can bring. I think you have to keep in the possibility for a tougher roll of the die sometimes, and it's up to the player to figure things out. Not that I haven't tried damned hard for clarity! But I don't mind it sometimes being quite a bit trickier.

Maybe the young boar could be missing the big teeth

I quite like that one! I'll have to check it doesn't overlap with any others (though I can't see that it would) then I may add it to the list...

[gimymblert]

Well we agree I use quote on tell precisely for the reason you mention
I would have more to say about handling "clarity" in how it relate to subtleties (especially in procedural settings) but it's not fully formed yet and my grammar is still to broken to try expressing myself right now.

But however we are entering nitpicking territories, just keep working on your game it looks really good and the art is amazing.

[Ultima Ratio Regum]

Well we agree I use quote on tell precisely for the reason you mention
I would have more to say about handling "clarity" in how it relate to subtleties (especially in procedural settings) but it's not fully formed yet and my grammar is still to broken to try expressing myself right now.

But however we are entering nitpicking territories, just keep working on your game it looks really good and the art is amazing.

Many thanks! It is nitpicking, but there's nothing wrong with that. Establishing clarity in procedural games is an interesting topic precisely because you can't "pace" things quite as easily and introduce everything early. Hmm. I'll have to think about it, and I might post some writing on this at some point .

[gimymblert]

If I may add a little bit, I will say that I think it's best to leave complexity in the structure not in the definition of its constituent. For example rubiks cube element are very simple to get, it's the structural manipulation that is hard.

In the context of "information flow" riddle, it's about how each bit of information add up to an image that lead to the solution. In the simplest form the final image is the solution, in the complex form the final image is another riddle (enigma).

And this can be nested, let's call "conceptual breakthrough" the realization (or insight) of a new information from the player of piercing basic element together. Let's look at the premise of romeo and juliet:
- Romeo is a Montague
- Juliet is a Capulet
- Capulet and Montague hate each other
- Juliet and Romeo love each over
The conceptual breakthrough here is the realization of the potential drama as hate/love statement contradict each over, let's call "forbidden love" the new piece of information born from this realization, it's not contain in the basic statement nor is possible if one statement is missing (and the drama is resolve if one statement is no longer true, which allow for story resolution, in this case, Juliet faking her death is an attempt to erase the Juliet is a "capulet statement").

This new bit of information can be further be a new statement for a next conceptual breakthrough. If the solution is based only on "insight" then you have a complex puzzle, and you can increase complexity by having recursive insight and increased insight depth (insight based on insight).

Pacing can be resolving by pacing the effect of statement order, statement are independent but insight depend on statement (or ... *introduce lock and key relative to statement order and insight*

Ooups my netbook is shutting down randomly, I post to save this and will continue later if you find this interesting! My alim died on me ...

[Ultima Ratio Regum]

If I may add a little bit, I will say that I think it's best to leave complexity in the structure not in the definition of its constituent. For example rubiks cube element are very simple to get, it's the structural manipulation that is hard.

In the context of "information flow" riddle, it's about how each bit of information add up to an image that lead to the solution. In the simplest form the final image is the solution, in the complex form the final image is another riddle (enigma).

And this can be nested, let's call "conceptual breakthrough" the realization (or insight) of a new information from the player of piercing basic element together. Let's look at the premise of romeo and juliet:
- Romeo is a Montague
- Juliet is a Capulet
- Capulet and Montague hate each other
- Juliet and Romeo love each over
The conceptual breakthrough here is the realization of the potential drama as hate/love statement contradict each over, let's call "forbidden love" the new piece of information born from this realization, it's not contain in the basic statement nor is possible if one statement is missing (and the drama is resolve if one statement is no longer true, which allow for story resolution, in this case, Juliet faking her death is an attempt to erase the Juliet is a "capulet statement").

This new bit of information can be further be a new statement for a next conceptual breakthrough. If the solution is based only on "insight" then you have a complex puzzle, and you can increase complexity by having recursive insight and increased insight depth (insight based on insight).

Pacing can be resolving by pacing the effect of statement order, statement are independent but insight depend on statement (or ... *introduce lock and key relative to statement order and insight*

Ooups my netbook is shutting down randomly, I post to save this and will continue later if you find this interesting! My alim died on me ...

Phew, sorry for the slow reply. It has been an insane week. Anyway - I think the Rubik's Cube example is interesting. When I was younger I loved the things, and managed to get down to about 30-second solves on a 3x3x3. As you say, I really admired the way it has such a simple mechanic, yet built up to such a high level of complexity. The same could obviously be said for Chess, Go, poker, whatever. However, I confess I generally prefer games that gain their complexity "from complexity", as it were, not gaining complexity through seemingly simple rules. In some examples I agree with you, but in other cases I think it's fine to have complex components as well as a complex structure/outcome.

I think your section about statements is a very interesting way to look at it! What is interesting about that example is that two different sequences would work. If you first knew the families hated each other, then learned they loved each other, that would have one effect on the reader/viewer; alternatively learning two people love each other then learning their families hate each other would also have an effect, but a slightly different one. As you say, the sequence/pacing is really important.

I think there's a great place for emergent properties of games, but I also don't feel that's the kind of game I'm interested in making. I'm sure some will arise, as they do in any system of sufficient complexity, but I'm more inclined to create a wide database of options/strategies I planned/intended, even if I@ll be interested to see what everyone else comes up with too. Hmm. I'm not sure how much sense that last point makes, but it's the best way I think I can express it. In terms of pacing, then, I am still unwilling to put too many limitations, or be too exact, about the order the player gains information, as I think different orders of info - as in the Romeo and Juliet example - can lead to different perspectives on the "same" situation.

[Ultima Ratio Regum]

So, here's a huge update on the past fortnight or so, when (despite my silence!) I've been damned busy. This week’s post is a big update on what I’ve been working, which is a combination of graphics, inventory systems, limbs and player health, and allowing for lightning (e.g. torches) external to the player. Firstly, I’ve been implementing graphics for various items. One of these is bottles – whilst the game does not contain “potions”, it’s going to be important to be able to transport various liquids. I currently plan for this to be possible via glass bottles, and waterskins, with each balanced a little differently – glass bottles can hold anything, but might be smashed in combat, whilst waterskins can only hold one substance (as it soaks into the material – so you cannot use it for poison, then water), but cannot be destroyed in combat. Although not a key component of 0.4, I decided a day or two ago to work on the bottle graphics, since I was taken by some of the ideas I had, and here’s what I came up with. Firstly, below, are four examples of possible substances in four different types of bottle. The top-left is water, the top-right is oil (notice the subtle sheen?), the bottom-left is blood (the most stylized of the bunch), and the bottom-right is poison.

There are currently five different shapes of bottle (all shown below, though I might add a sixth too) – these shapes have no gameplay effect, but are just for variation. Each has five different levels for the substance inside – full, three-quarters full, half full, one-quarter full, and empty. Once empty you will be able to refill them from an appropriate source (like blood from a corpse, water from a river, poison from a deactivated poison trap, etc). There are, as above, currently only four substances, though I can imagine several others that might be useful in the future. There are therefore at the moment exactly a hundred different permutations of glass bottles (5 designs, 5 levels, 4 substances). Thus far this is the highest number of permutations to date, I think, for any particular graphic, and will only continue to grow as I add another type of bottle and various other substances.

I’ve also remade the inventory (for the final time). The inventory in 0.3 is effectively a “fake” inventory – you can only pick up the three key segments, and you cannot drop them, and only one aspect of the inventory can be accessed. Additionally the system for picking up wasn’t “real”, in the sense that the items were implemented in a way which couldn’t really support anything other than the three key segments. This entire debacle system has now been changed in several ways. Firstly, when you try to pick up an item on a tile with more than one item, it produces a list of possible items (shown below).

You can then highlight the ones you want by pressing the appropriate letter, and press Enter to confirm your selections. Those are all then added to the appropriate inventory sections. The inventory itself, meanwhile, can now handle, sort and allow you to select arbitrary items from any category. When you open your inventory categories with > 0 items in will appear white rather than grey. Also, opening your inventory for different purposes – looking, dropping, using, etc – will obviously have a different label. You then select the appropriate inventory subgroup and do whatever it is you opened the inventory for. Esc or any movement key will get you out of this screen.

When you select an inventory sub-group, it then brings up a list of everything in that subgroup. I debated just having one large inventory for all items, but I decided against that for various reasons. Firstly, because some inventory classes have limitations – for instance, you will only be able to carry one long weapon with you – and I felt this needed to be clear. Secondly, some inventory categories might have large numbers of similar items, for example lots of branches for making torches, and I didn’t want that to “clog up” other inventories. Thirdly I suppose it also serves a small gameplay effect for showing you what category certain items fall into, and fourthly, I just felt having a “main” inventory menu looked aesthetically nicer. I did a lot of practice with it and much like one becomes used to doing several-stage macros in Nethack or Crawl, so to does one quickly become used to clicking the shortcut to the right inventory area. One of the items I’ve now implemented graphics for is the torch, which looks like this:

Torches have five different images which reflect how burnt down they are (0-20%, 20-40%, and so on), and there is also a different colour of wood for each type of branch (the above being olive, and 20-40% burnt), resulting in something like eighty different torch images or so. I am currently in the process of adapting and balancing the extent to which I want torches to boost your vision, and also to allow the player to make torches via the new ‘m’ake command. “Crafting” will not be a large part of the game, but there will be a few situations where you will be able to combine items to others. I’ll have more on this screen and this mechanic once I’ve worked on it a bit more, but you’ll soon be able to use flint, stone and a tree branch to create a torch (i.e. creating a spark with which to light the branch). Over the next week or two I’ll be looking to implement the difference in torch radius when you wield a torch, and allow you to wield and un-wield them. You can also now drop items, either singly or in large numbers, much like the pick-up-multiple-items menu; you are given a list, you highlight the ones you want, then press enter.

Next up I’ve been working on the health and limb system, which has undergone a not insignificant number of changes over the lifetime of the game thus far. I’m implementing this now because traps need to be able to hurt you (funnily enough) which means that acid burns, fire burns, physical limb damage and all the rest of it need implementing. The first part of this is ensuring that limbs all display correctly when you look the player (and later at other foes). This can either be done by ‘l’ooking at yourself, or pressing the ‘@’ button. Here’s a quick preview of how the three screens currently look (they can be tabbed between):

The second and third screen are largely placeholders at the moment, since you cannot change your clothes/weapons nor gain or lose any allegiances aside from the civilization and religion you start off belonging to. The first screen, however, now displays whatever dreadful ailments have befallen your character, as in the example below:

And also, as we can see, whatever healing items have been applied. I’ll do a full blog entry later on how health and healing are going to work since this entry is getting long enough already, but items like bandages, sutures and splints are going to be important to healing various parts of the player’s anatomy. Also, you really don’t want the rotting status.

Lastly I’ve also worked on external lighting sources, though they are still very much a work in progress. When you drop a lit torch, it currently lights up an area around the player (the radius is not yet fixed or decided; this is just a proof-of-concept example). If you can see the external light source, you will be able to see everything in it, as in the left picture. In the right version, there is a tree trunk  between you and the light source; you can therefore see parts of it, but not all of it. You will not be able to see creatures or items between you and an external light source if there is a gap between the two – whilst obviously in the real world you would see a silhouette, I think it would make for more interesting gameplay if you could only see foes when they’re in lit areas, thereby perhaps allowing you to place and move light sources strategically to keep track of enemies.

What I’m not yet sure about though is the relationship between external light sources and undiscovered terrain. In this example, although you haven’t explored the middle you can still see through it to some of the light source, but since parts of it are blocked, you can reasonably deduce there is probably a tree or two in the shroud you cannot yet see. This model treats undiscovered areas the same as areas you’ve discovered but cannot currently see – you can see through them, but you cannot see into them.

Whilst I think the first two implementations both make sense, I’m really not sure about this one, so leave thoughts on whether you think this makes sense, or whether undiscovered terrain should totally block your line or sight. I can see arguments for both versions. That’s quite enough for this week – next week I’ll probably be moving onto discussing either traps, limb damage, or both, in more detail, but as ever let me know what you think of these latest steps towards 0.4! As a whole, things are well on track for a winter release, and now that I actually have a working microphone again, I’ll be looking to stream more coding sessions and Q&As and the like in the near future – stayed tuned to Twitter (https://twitter.com/UltimaRegum) & Facebook (https://www.facebook.com/UltimaRatioRegumRoguelike) for details…

[gimymblert]

Phew, sorry for the slow reply. It has been an insane week.

haha don't worry, I forgot to revisit my post too after I got back on tigs

Anyway - I think the Rubik's Cube example is interesting. When I was younger I loved the things, and managed to get down to about 30-second solves on a 3x3x3. As you say, I really admired the way it has such a simple mechanic, yet built up to such a high level of complexity. The same could obviously be said for Chess, Go, poker, whatever. However, I confess I generally prefer games that gain their complexity "from complexity", as it were, not gaining complexity through seemingly simple rules. In some examples I agree with you, but in other cases I think it's fine to have complex components as well as a complex structure/outcome.

Oh, but I'm not advocating that level of simplicity, i just use a "simple" example to illustrate that complexity arise for very simple and clarified elements. For exemple we could have a rubik's cube where color would be matching family, with a notice of how each family match together, and different manipulation to move row based on its member attribute ... the rules are no longer "simple" together, there is an overloading of memory, perception and manipulation. Yet each element separately are still very clear, their relations and accumulations are what made it complex. It's a matter of sliding the scale up and down as long complexity is not confused with confusion.

In fact I was addressing concern over ambiguity and forgot to address it in depth too. Ambiguity can be "clear" too we just need to avoid confusion over the domain. Ambiguity happen when a statement can lead to many solution, for example "on the side" depending on the context can mean "left or right", sometimes its clear which side because other statements bring the correct insight, however without enough context the other non solution can became a red herring, depending on how trivial is the red herring (how many check i need to dispel it, can it lead to further red herring insight?) you can literally measure the confusion level. There more to say but I'll stop here, that's the gist of it.

I think your section about statements is a very interesting way to look at it! What is interesting about that example is that two different sequences would work. If you first knew the families hated each other, then learned they loved each other, that would have one effect on the reader/viewer; alternatively learning two people love each other then learning their families hate each other would also have an effect, but a slightly different one. As you say, the sequence/pacing is really important.

Yay, I didn't have to explain it too much you got it, the different impact is mainly emotional as the data remain the same, however insight based on outside knowledge (real world knowledge of people psychology) may lead to parasitic statement (red herring).

In fact "speculation" is a kind of insight that's part of the tools, ie intentionally hiding information so the knowledge model is (more or less) obviously lacking a statement that prompt the audience to try to fill it for closure. The tension between speculation and reveal is how story works or interesting puzzle keep interest.

It's important to remember that we are talking about puzzle, I use exemple from "story" because story are puzzle at heart and therefore share similar quality. It's apart of my works on procedural storytelling for games.

And regarding the order, it's important to keep track that the level design can suggest an order, it might be important to review and manage the order to keep the player freedom (avoiding red herrings). Another aspect is how important (or not) the player understand he had all the necessary clues (did he miss one?).

Another aspects I had to work out for this analysis is what define an information. I conlude information is any significant change between two state, ie change is information. If you multiple boar with similar pose and different pattern, the pattern are seen as an information because it became the significant change, context and other clues can help reducing this effect, but it need to be managed. Controlling the "language" of change is how you control the arbitrariness of elements.

I think there's a great place for emergent properties of games, but I also don't feel that's the kind of game I'm interested in making. I'm sure some will arise, as they do in any system of sufficient complexity, but I'm more inclined to create a wide database of options/strategies I planned/intended, even if I@ll be interested to see what everyone else comes up with too.

Notice that the tools I'm laying down are not "emergent", as in what people usually think for games (divergent possibilities). It's the opposite of that, I'm laying down the structure of puzzle so that we can control the player experience like we want.

It's all about control and indirection, the romeo and juliet premise is not divergent, it only need to what the author want the audience to understand in a non direct way. A more direct way would be to spell out the trouble of romeo and juliet directly, instead we hide it using hint to create an insight (one level of indirection) in the way we want (control). By measuring the level of indirection (hierarchy of insight), the complexity (how many insight/hint to get a significant insight), the level of confusion (red herring statement and red herring insight), the speculation and anticipation, the saliency and proximity of hints (whether they are insight or statement), we effectively funnel a player where we want to go. And because those element are atomic and measurable to an extent, we can build a set of construction rules for procedural purpose that create the effective experience we want out of it!

I mention salience and proximity and didn't explain them before, but I think it's obvious. You get part of proximity in the discourse about "pacing", it's easier to link two statement that are close (which could also be used for red herring). Salience is when a statement is emphasized (high saliency) by various technique (repetition, building up, etc...) or deemphasized (low saliency).

In bioshock infinite in the beginning with a good example of those last aspect. Baptism and nosebleed (once we wake up on columbia) are introduce early on and have long distance with keys statement that give them meaning, creating strong insight. But while baptism is constantly reinforce as it ties to the main arc, the nosebleed have less salience and only lead to speculation about background aspect that shed different perspective on the main arc.

In the context of your game, it is simple, it mean that the puzzle must have strong and self contain statement that lead to a resolution, yet can still have low and insanely complex web of statement for the lore, building up mysteries and discoveries upon each other. In fact in the context of a procedurally generated universe, you can lay clue in a way where the story and lore in procedurally generated in the HEAD of the player in a controlled way!

Hmm. I'm not sure how much sense that last point makes, but it's the best way I think I can express it. In terms of pacing, then, I am still unwilling to put too many limitations, or be too exact, about the order the player gains information, as I think different orders of info - as in the Romeo and Juliet example - can lead to different perspectives on the "same" situation.

I'm just laying down tools, not suggesting a way to do it , the goal is to give a clear view of your playfield so you can do the best move with the best clarity. Or fix problem by having a better analysis of what you want and what goes wrong. That's things you can play with at your heart content. I hope you enjoy it and that it will be useful to some degree (even without going in that depth).

Your game shape up quite nicely so far and the graphics are still amazing!

[Ultima Ratio Regum]

Hmm, interesting. I like the distinction between ambiguity and confusion, since I use "ambiguity" to mean that the solution won't be clear, not to mean a clue might have multiple outcomes you have to figure out the right one from.

I agree it's very important to keep track of the order in which the level designer can produce different elements. As is often the case, I adhere to a similar design philosophy as Dungeon Crawl - things should generally advance in a logical order, ie puzzles get harder, but I don't mind having an out-of-depth puzzle either. I fully agree re: the language of change - as I mentioned, I was surprised that anyone would consider variation within "identical" images, like multiple boars, had any relevance. Just an example of me reading the game in one way, as the dev, and someone else reading it in a way I never thought possible.

I think the self-contained part is essential; even if you start off with an out of depth puzzle, it should still be solveable without prior experience (which I feel they are), and in the process it builds up your knowledge of what exactly the terms in question mean. I'm really looking forward to adding some of the lore elements into the puzzles too, though I'm not totally sure how yet. One thing I'm puzzling over at the moment is how I want to implement languages and keep it as an interesting factor, and not just an annoying obstruction to translating puzzles. That needs some thought. And thanks!

[Ultima Ratio Regum]

Just a short update today as it has been a busy fortnight. Firstly, some housekeeping. For those of you who don’t know, I’ve taken to streaming URR coding (and answering game questions etc), and also streaming Dungeon Crawl and a few other games, on my Twitch channel (http://www.twitch.tv/maasbiolabs). I’m planning on streaming a lot more both coding and games as time goes by, and I’ll be announcing these only on Twitter (https://twitter.com/UltimaRegum) (since I don’t want to fill up the Facebook page or anywhere else). If you want to ask questions about the game or see it coded and playtested, do stop by .

Now, onto the actual update which, as promised, is pretty brief (though what it describes is pretty significant!). Firstly, you can now throw items. Doing so brings up a crosshair, this time yellow (the ‘l’ook function is white, whilst the ‘g’rab function is orange), which also produces a “tail” behind your cross hair which shows you whether or not your throw will reach its target, sections of which will light up red if you’re trying to throw it through something you can’t. You then press enter, and the item soars across the map (some items spin whilst flying, so a torch will display as ― / | \ whilst flying) and hits whatever. I’ve also enabled a system for a message to display both when the item hits something, and when it lands, along with any other effects. For instance, you might get “The torch hits the wall”, or “The torch lands on a fire trap”, or “The torch hits the wall and lands on a fire trap” if you aimed the throw at or beyond a wall, it hit the wall, and then comes to land on whatever is below it. Additionally, some objects now set off some traps. Anything passing through a tripwire (not over a tripwire – it must land on the tripwire) will set it off, and heavier objects landed on pressure pads will set them off. You will also soon be able to ‘u’se branches to, rather than just throw them at traps, prod a trap in any square adjacent to you. Bear traps cannot be set off by something as light as a branch landing on them, but they will be triggered if you push down on the trap with one manually. Naturally all of this need will need balancing in the future once I know how much the player can carry, the scarcity of items, etc, but I’m just focusing on the mechanics for now. Below are two pictures of valid and invalid throws:





Secondly, torches now produce lighting whilst they fly! It is a very, very cool effect, and means you can now throw torches into the darkness to see what’s ahead, if so inclined. There will be very little in the current release that you might need to do that for, but in later versions it will be of much more use in certain situations (though you’d always run the risk of alerting people up ahead). The image below should give a vague idea of what it looks like, but I’ll try and produce a gif of it at some point.



My next objectives are making sure all the interactions between objects and items on the map a) are correct and b) give correct messages whether in or out of sight, working a little more on tripwires so they spawn correctly in some unusual map situations, and finishing off the trap graphics, around 70% of which have thus far been done. After that I’ll be working on the ‘m’ake menu for combining items (for example, constructing torches), and then I’ll be moving onto the second big part of this release, which is health, damage and healing items. Well on track for releasing 0.4 before the end of this year! I’m also going to start producing much more detailed changelogs from here on (akin to something like Dungeon Crawl) since there’s always a lot of tweaks and minor new features I end up fitting in.

[eigenbom]

Looking awesome dude! About changelogs: make sure they don't take too much of your time.

[Ultima Ratio Regum]

Looking awesome dude! About changelogs: make sure they don't take too much of your time.

Thanks - and this, I think, is sage advice. I have a list of stuff to do for this release, so my intention is just to publish that as the changelog, really, so it shouldn't much time itself. Hopefully.

[Ultima Ratio Regum]

Well, a lot of coding later, traps, projectiles and throwing are all pretty much finished, and a large quantity of the new items for this release and the new dungeon features all have some rather nice graphics associated with them. 0.4 should be finished well before the end of the year at this rate, but I'm still aiming to release around the end of the year (with just a little bit more time for tweaks and optimization). I've started adding bottles into the game,and I'm currently working on the minimal crafting system the game is going to contain (it's only a very, very small part of the game). Meanwhile, this week's blog entry is a piece about Metro: Last Light, and how well it combines environment and gameplay design (and how badly it handles item balance), so let me know what you think if you're interested: http://www.ultimaratioregum.co.uk/game/2013/10/05/thoughts-on-metro-last-light/

I'm still streaming coding a lot on the twitch link in the posts above, so do stop by if you want to see the game being developed/playtested. I'm really happy with how traps are working out, and soon I'll be working on the health/damage/limb system, so that they can actually start hurting the player...

[Ultima Ratio Regum]

Here's the latest updated, cross-posted from my blog:

This week we’re going to talk about the languages in Ultima Ratio Regum. These have two components – the visual side, which is this week’s topic, and the coding side which allows the game to build up full dictionaries for each language. The latter side isn’t yet fully implemented, and I’m still working on how precisely language as a mechanic is going to work in-game, but as those who played the last version will have noticed there were a large number of possible fictional languages. If you looked in the game’s files, you’d have noticed sixteen languages, each in the 12×12, 10×10 and 8×8 font sizes. This entry is about how I went about creating these, what each is based on, and some of the restrictions I discovered I had to impose in order to make languages visible and distinct in as little as 8×8 pixels. I’m only going to cover some of the language here; by my own admission some are less interesting, and some more obvious in their origins, so I’m going to only cover the ones I think are the most intriguing, or that required the most work or research to bring to fruition. The game mechanics side of the in-game languages I’ll cover at some point in the future once said mechanic does, in fact, exist…

The first language is based on various runic alphabets.



I confess that such alphabets are routinely used in various fantasy contexts and on this count I haven’t been particularly original here. I’m not quite sure why languages that look this way are so popular, though a few rationales present themselves. They’re clear and all aesthetically similar; they look like the kinds of characters that could believably be hewn into ancient rock with only basic tools, rather than more intricate or curving designs; they are somehow rather striking and lack any real ambiguity or potential to confuse one letter with another; and perhaps the cultural pervasiveness achieved by our long-dead Viking ancestors above many other non-extant civilizations has something to do with it too. Regardless, I started off with these because they could be drawn with clear, thick and straight lines, and could easily be scaled upwards or downwards to different font sizes. Despite some fairly heavy restrictions in terms of focusing on straight lines and as small a number of those lines as possible, a decent level of variation was possible. Here’s what the language looks like in the end:



This second language is inspired by Rongorongo, the as-of-yet untranslated series of glyphs (linguists are uncertain whether it is indeed a “language”, or perhaps a form of mythological archiving or memory aid) found on Easter Island.



 I’ve always found Rongorongo to be a particularly aesthetically pleasing language with its combinations of half-ambiguous plants, humans and fish, and I find something quite enticing about the fact we don’t yet know how to categorize it – a language, a proto-language, or something else altogether. That it has held its mystery strikes me as an interesting aspect of the language, and I wanted to try and echo something about the lack of clarity Rongorongo displays about whether the images are letters, direct representations, or something else altogether. This was a much tougher language to create due to the intricacy of some of the designs – I was eventually able to make them all identifiable at even the 8×8 font size, though some were a lot trickier than others. I think this one turned out well and has a certain feel to it the other languages (not being at all symbolic) lack.



This next language is based on Hindi.



A language joined up a consistent line, rather than the ways in which handwriting is “joined up” in western European languages, was one I wanted to make from the start, whilst still making sure it remains distinct from any real-world equivalents. This one was both enjoyable and relatively simple to make, and scale down to the 8×8 font, though the application of a horizontal line imposes a few minor restrictions on it I haven’t yet worked out ways around – for instance, if generated around a ziggurat door. I will likely simply prevent this language image from being chosen in such situations, though I hadn’t done so just yet. However, long sequences of this language look very nice in-game, and contributes further to trying to produce a variation in linguistic aesthetic reasonably comparable to that we see in the real world.



The language below is based on cuneiform (much like, for all intents and purposes, the dragon language in Skyrim).



 Much like the runic language, this one is very clear at all scales, and also lends itself to a variety of combinations of length and orientation of indentation. Equally, the way in which one can imagine such a script being carved into rock has always given the language a particular interest for me, and thematically I find the origin of such a language being centuries or even millennial before the start of the game very believable. The fact the tools used to carve the language are reflected in the language itself lends it, I think, a very unique air:



The next language you see below was a very deliberate attempt to make a language that differed widely from all the ones above. I can remember looking at the current file of languages and trying to think of an aspect I hadn’t used – many diagonal lines, or several curving lines – before realizing none of the languages so far used dots alongside other components. One was composed entirely of dots (not shown in this entry), but none uses dots in small amounts or as an accompanying part of the script to other aspects. Thus, I created this language, which was envisioned as a combination of curves and dots in different quantities, and one I think turned out very well:



Now we come to one of my favourite languages. I think this is one of the best languages I’ve created thus far, though it is not based in anything in particular (beyond labyrinths and mazes). This was one of my attempts to create a totally unique language, and I certainly can’t think of anything resembling it in either modern times or earlier history. Some parts bear passing resemblance to certain tiles in logographic east Asian scripts, but otherwise I wanted to make this language very detailed, very dense, but with a clear geometric preference for orthogonal lines and right-angles, and generally only a single consistent line that makes up the entire letter. Although it may not look it, this one translates well into small font sizes by simply reducing the numbers of loops, for example, a particular character in the language has.



Ultimately, what struck me as the most important factor was the internal consistency in each language. When one looks across languages, even those character seemingly very different, clear differences between scripts become very clear – whether alphabetic, syllabic or logographic, each has a preference for straight or curved lines, a willingness (or not) to use dots and other small markers, restrictions on how the language may be constructed, a way of joining up characters (or an insistence characters must be kept separate), and so forth. The languages for the game have tried where possible to reflect this, and to generate a reasonable amount of variation for each language whilst still staying within logical boundaries. Equally, there are rare cases where certain characters have been maybe slightly changed or slightly simplified just to aid ease of writing (or reading), and in some of the languages I tried to add a character or two that were slightly different, but could conceivably have developed from a slightly more awkward variation of the same character. There are perhaps another half a dozen languages in the works too, but they probably won’t make it into the game until 0.5, when full civilization and history generation will be implemented. It is worth adding, for those unaware, the name and the dictionary for a language will be generated at random each game. Which is to say, the “Hindi language” might have one name one game with a particular set of words assigned to it, whilst it will be totally different next time. Once 0.5 is implemented the game will generate a dozen ancient languages, assign names, dictionaries and images to each one, and then populate those in global ancient ruins logically. All contemporary languages in the game will use a contemporary Latin alphabet, albeit with a full potential complement of umlauts, accents and other diacritics.

Lastly, and as I’ve mentioned elsewhere, I’ve now hit over 1000 followers on Twitter, so this coming Sunday (the 13th) I’ll be doing a celebratory all-day coding/playtesting stream from (roughly) 12am GMT -> 12pm GMT (www.twitch.tv/maasbiolabs). Do please stop by and say hello; I’ll be following it up with (most likely) some Dungeon Crawl Stone Soup in the evening, so if you’ve ever wanted to get into the best classic roguelike out there, be sure to tune in. Next week I’ll be doing another big URR update as I finish off everything in the release that isn’t health, injuries and death, after which –  you guessed it – we’ll be moving onto health, injuries, and indeed, death. Stay tuned!