Housekeeping Notice: I’ve just finally found a way to stop WordPress resizing my images! But, this might break something without me anticipating it, so please let me know if anything looks odd on this entry.
Hello everyone! Great news this week – I have now implemented, and played, the entire tutorial quest from start to finish. And then, of course, played it again, since it’s different every time. And again, and again, and again, and it is with immense pleasure that I can say it actually works, it plays well, I think it gets the points across very nicely, and this also dovetails with the stuff I’ve been working on in the previous weeks, with changing the conversation system, as speaking with the curator both before and after embarking on the quest itself are important parts of the whole process. As such, no matter what university generates, how the buildings look, what the buildings are, and any of that stuff, the game can now successfully create a quest with two steps in it, one having you look for something outside, and one having you look for something inside, which connect together logically, are generated partly through rhyming clues and partly through visual clues, and eventually takes you back to the curator, who thus rewards you and sets you on your way. I am so, so, so happy with this, as this is my first trial of quest generation. It’s a quest unlike all the others, sure, and it’s a “special case”, but it proves it can be done! The game can take the world data and make clues from it (or make clues and then force the world data to line up), stitch them together, register when the player does something correct or incorrect, and then give you the next required parts of information, all for a generated set of riddles in a generated world. This is fantastic and really shows that the “general” quest generator, i.e. the thing that will make every other quest in the entire game, is feasible and only weeks away from at least a basic implementation. I know a lot of my recent posts have been very technical, but all this shows that it is actually coming together, it’s actually working, this mad strange thing I’m trying to build! This is very exciting. So, without further ado, let’s get into it:
The Curator
First task was to add the curator, who is the curator of the museum you start in, and the person who sets you off on your quest. In the current version you spawn in a room near the main museum in the university of the nation you randomly start the game in, and so I just needed to add the curator. There is an unused character (in the sense of “letter or number”) that I had already assigned to “Scholar” (a capital “H”) though I hadn’t actually implemented yet, but for a unique character I wanted a unique character (as it were). “C” was currently assigned to “Chief”, i.e. one of the potential ruler types, but the “Chiefdom” trait for nations isn’t really doing anything and is being deprecated anyway, so I disposed of that and assigned the capital C character to the unique curator character (“c”, by contrast, is used for “clerk”, and those show up plenty in various districts in capital cities and potentially elsewhere as well, so I didn’t want to replace them with something far too grand). So, “C” it is, and now the curator spawns in this room when you start the game, and has all the appropriate clothing and jewellery and so forth for whatever the generated nation happens to be. They’ll appear on the chair in that room, and they have a special custom schedule in which they just move between the chair during the day time, and the bed during night time; after you leave they’ll also sometimes wander into the museum to look at things there, and sometimes wander back to their chambers. I haven’t done anything with NPC scheduling for seven years and this really did take a bit of brain power to get going, but at the same time, I was quite pleased by how rapidly I was able to make this work and play out exactly how I wanted it to. I”ll also adjust the curator’s schedule so that when they are awake they will wander around the various chairs in the museum, the tables, and looking at the exhibits, but they’ll never wander down to the stairs and just wander away, and all of that only activates after the player has had their first chat with them, to prevent them just wandering off before you actually have a chance to, er, talk to them.
We then go into the initial chat, which has a set of custom conversation options that aren’t normally available in other chats with other characters. The curator explains that they’ve become aware that the world is filled to the brim with strange mysteries and riddles, and that a deep understanding of the world and its nature might be divined by seeking out the unanswered questions scattered across the globe. They then explain that they’ve set up the tutorial quest (though not of course using this exact terminology, as that’s a bit non-diegetic) and give you both the clues for that, and the initial clues for the main quest going out into the world (this doesn’t happen yet as I write this entry, but will very soon once I’ve built the actual quest generator!). In the future we’re going to have a procedurally-generated opening cutscene in the game’s ASCII / ANSI style (because of course we are!) but again, I don’t want 0.11 to take any longer, so I’m just getting straight into it by giving the player the information they need and assuming the player hasn’t seen the cutscene (which doesn’t exist yet) – I’ll come back later in 0.12, or perhaps a 0.11.x version, to add the cutscene in and just lightly adjust the dialogue here so that it actually makes sense. As discussed in recent entries, I want to make sure this first chat is very clear for the new player but also doesn’t take long for the returning player, and needs to get two important things across, i.e. both giving you the tutorial clues, but also giving you the “real” clues for the start of the main questline, and making clear that one can skip the tutorial clues if one is so inclined. I went back and forth a lot on these trying to get the tone and the presentation of the curator’s wording (and your questions and responses) correct in order to make all these points clear while still staying “in universe” in how these are expressed, but I’m really happy with how it all came out in the end. As part of this I also started putting in place some of the infrastructure for replies in conversations, and their replies to your replies, and all this has come together really smoothly as well. Here are some examples of how the chats might go (note that I’m going to add more variation soon, don’t worry!).
The First Half
With this done, you then end up with two tutorial notes in your inventory. The “real” quest notes (i.e. for beyond the tutorial) are not appearing yet, as that comes next once we get onto non-tutorial quest generation, so for now you gain the two first notes for the tutorial quest, and also a shovel. One of these notes is always a rhyming riddle – got to show off this system right away! – and has four stanzas, two telling you in detail what building you want to look for, and the other two telling you to go to a specific location shown on the other note, and dig. This is very basic stuff, but again, we want to start off basic. As I’ve noted before, for the time being at least, I need to assume 100% of my players are coming in from the roguelike side rather than the puzzle side, so this needs to be made very clear indeed – assuming everyone has played La-Mulana, hint-free, and actually figured anything at all out, cannot exactly be taken for granted. Cryptic riddle games are a tricky beast and take some getting used to because they demand thought processes that most games don’t, and demand attention that most games simply have no need for (and this is something one actively has to learn, i.e. anything and everything you see might be important and might not just be background, or lore, or worldbuilding, or whatever), so we’re starting off really basic. The second note, therefore, is always a local map style clue (i.e. not a world map style clue) depicting the outside of a building or area described in that first clue, with a nice red “X” marking the spot where you should go and dig. I debated making this area be anywhere around that building or area, but to keep things nice and simple, it’ll always show the door of the building that you need to dig outside – or, if it’s a campus gardens area, then it’ll always be a very clear part of the gardens that can’t be mistaken for anywhere else. Don’t want to run the risk of the new player getting confused, wandering off, not being sure where they should be comparing against their map, and so forth – keep things nice and easy. You then move to the right area, get your shovel, dig, and reveal a chest, containing two things: a note, and a key!
This, however, did of course take some coding. In previous recent entries I talked about the “.forced_generation” dictionary which tracks what things have been predetermined to generate in certain ways, e.g. building X must generate in orientation Y and subset of interior Z because there is a clue already made pointing to a specific thing, in that building, in that orientation, and that interior, so even though it doesn’t exist yet, we need to be sure it will exist when we come to it. This is a really important addition and one that I’m continuing to refine, adding in a vocabulary of different things that can be forced – e.g. yes, sometimes it’ll be a building in a certain way, but other times it might be a particular chest must appear in a particular spot, or a particular statue must have some damage in a particular way (although again not yet actually generated), and so forth. This fortnight, though, I’ve added another thing for each map grid (i.e. each tile on the world map), which is the “.secrets” part. This part is absolutely key and I talked about a draft of it in the Roguelike Celebration talk I did last year, though it has been significantly refined and fleshed out since then. Each secret in a world map grid denotes a set of variables that must be completed to activate some kind of trigger, and the first we have therefore implemented is the dig trigger. When you did, the game looks in the list of secrets for that world map tile (if there are any secrets there, of course), and if so, cycles through them to check whether any of them begins with “Dig”. If so, then it checks what the next element is, which for dig is always a pair of x and y coordinates on the local map, which in this case were selected when the local map clue was generated, and then added to the secrets list. If the player is indeed standing there, it then checks any of the other elements to see if anything is missing – e.g. later elements in this list might be things like “during a full moon” or “in summer” or “with an ally alongside” or whatever, but for now, this is empty – and if those all check out, then my goodness, the player has found a secret.
So yes: in that first chest, we find a note, and a KEY. I felt it was important to do as much as possible in this tutorial quest, so this first step hits a number of goals – introducing the player to rhyming clues, to local map clues, and to digging stuff up, which are all important. It also introduces you to chests and how they work, i.e. the player has to open the one they dig up and extract the stuff within. This second part has another rhyming clue (forgive me, but I want to show this one off, I can’t help it…) but this time directing you into a building, and relying on your reading of the clue’s description instead of a local map to tell you where in that building to go. Here I’m trying to show the player that you won’t always have a visual clue to find a visual thing – in this case, a location – and also of course introducing keys, and locks, as a way of making sure the player has a good sense of how these work. Obviously that’s not the most complicated thing, assuming that they have either a) played any other game ever or b) actually exist on this earth, but nevertheless, I think it’s worth demonstrating – as it also shows that unlike in some games where the correct key is automatically chosen from your inventory if you have it when trying to open a lock, here you do actually need to select the key which you think is the right one, and use that in the padlock to proceed. This second note, in turn, directs you to a building that you didn’t interact with for the first clue – i.e. they will never be the same building – and this usually means either the great hall where you start (the museum being on the upper floor), or the library, of that university campus. You head inside and you’ll always find four chests spawned, only one of which will match the precise description in the note, e.g. “sits alongside two tables and a wall” or “sits alongside a lone chair” or “sits by a chair and a bookcase”, and so forth. See here in this example, how the chest is precisely described by the clue, but other chests in this building won’t be:
Then you head to that chest (once you’ve figured out what building is being talked about in the first pair of lines), use the key, and you get your final note of the tutorial quest, which directs you to return to the curator. This was another fun rhyming generator to create, yielding notes such as this:
Then you head back and you get some new dialogue in which the curator congratulates you, and gives you some general gameplay hints. As I discussed in a recent entry, we can’t have the curator reward you with specific information for completing the tutorial, because otherwise that will encourage even experienced players to go through the tutorial again just to get some initial hints on the game’s main quest, and that would be undesirable. Instead, the curator essentially repeats some of the stuff which the game’s tutorial prompts say, but does so (obviously) in a more diegetic / in-universe fashion than the tutorial prompts do, and which I think the player needs to know. This is stuff like the importance of looking at the names of things, the importance of looking at how things look, the importance of always considering simile and metaphor (two of my favourite things for obfuscating information), the importance of thinking outside the box, and the importance of using all resources available to you (notes, books, maps, characters, in-game objects, items, and so forth). I think it’s worth just continuing to hammer this home for the new player, but it won’t be anything the experienced player will ever have a need to go back to again, unless they somehow become uncertain or forget what game they’re actually playing. I’m really happy with these hints and I think they offer a good chance to be very explicit about what you’re meant to be doing. I also like the final bit I was able to add in here; while I wouldn’t expect most players to twig it, that final line is implying (for 0.11) that this is just a first version, and other stuff may well come later, but for the time being you’ll have the clues in your inventory – and whatever clues those lead on to in turn – to be exploring. And with that, the tutorial quest will be completed; the curator will no longer have much else to say; and you’ll (soon!) have the two “real” starting clues, beyond the tutorial clues, to be going on with in your explorations of the world. I’m really, really, happy, with how this quest plays out. It still needs some playtesting, and I can immediately see an issue for the new player – how do they know which building is which? – and that’s something I need to resolve, but overall this feels like an actual tutorial request requiring some brain power (though not too much), and getting all the important points across.
Chest Spawning
One of the main complexities in the above came from having a chest spawn indoors in a building – the question was how to decide where such chests can and cannot spawn, and how then in turn to generate their location descriptions. My first idea was to have a model whereby I go through all 2148 (!) of the entries currently in the dictionary of generative items and identify a number of places where a chest could spawn within that building (or outside the building, as plenty of these show outside areas rather than inside areas). This, er… ran into an obvious problem, which is that this is a colossal task. It would also require me to keep track of what characters aren’t being used in every single generator which I can then use for the characters for chests, and that would be a huge task as well (though there is way to automate it somewhat well, though my actual use of it would then be potentially quite prone to mistakes), and I also ran into other potential issues here as well. The game would need to be able to keep track of what chests had been pre-selected if required when the game half-generates a place prior to the player’s actual entry into that space, which would become even more complicated with rotations, and maps, and having many possible chest locations, and the whole thing just seemed to be spiraling out of control in an entirely dreadful manner. While this might have indeed worked had I been coding the entire game from scratch with this exact functionality in mind, right now it would be far too great a task to put in place. As such, I then started to think about other ideas, and instead I thought: well, what if I write a function into which any building (real or not yet real) can be put, and the game can look over the building, find the most interesting and aesthetically logical places to put (a) chest(s), and place them there? This seemed like a splendid notion at first, but then I ran into two potential issues as I pondered it a little further. The first of these was in programming the game in such a way as to know what a “nice looking” location for a chest is. This might seem like an unimportant thing, but a bit of consideration showed me that it would really break the overall aesthetic style of the game to have a chest just in a totally geometrically random location in a building, e.g. half way down a corridor, say, or four tiles from one wall, twelve from the other, and with no obvious reason for it to be there instead of somewhere else. I spent some time imagining how to create a function that would look for “sensible” locations, and while I had a good idea how to do this, in the end I felt this was going to become a pretty demanding thing to write.
The other reason, far more simply, is that it would add to the game’s processing time when generating buildings or when generating clues. What if it doesn’t find a good spot across many cycles and has to keep looking for ages? I’m trying so very hard at the moment, and have been for several years, to optimise and polish everything I can find (though there is still plenty to go on that account, I’m fully aware) and I’m extremely reluctant to add in something else like this. Increasingly now when the choice is between “a lot of labour on my end” or “something that will add a few tenths of a second into generation” I’m leaning more and more into the first of those. Many people over the years have said that they would like the game to be a little faster, a little more responsive, and I suppose I really have taken those concerns to heart. I don’t think this processing time issue would *often* occur, but I think it would occur sometimes, perhaps in particularly cramped buildings or situations where for some other reason it’s hard to find a good spot, and I just don’t like the idea of this at all. And – worst of all – what if it can never find a “good spot” (according to however I coded “good spot”) and just gets stuck? Obviously I’d code something in there to handle that so that would never actually happen, but that could still take up a meaningful fraction of a second trying as many locations as possible before concluding there’s no point in continuing, and going to a backup option instead, and the whole thing is just dreadfully inelegant. And having just said there were two reasons not to do this one, the third would be the huge complexity this would add to generating clues about that chest location if the location itself is wholly generated – I gave some thought to the kind of code that would be required to ensure visual consistency here in, for instance, a local map clue, and while I certainly could code it, it would be rather involved and would probably open up a lot of potential for things to go wrong.
As such, after all this pondering, I actually came back to the first idea, but a much smoother and easier version of it. I looked through all 2148 pieces of generator data, and discovered four characters that were never used in any of them = “¬”, “_”, “(” and “)”. These would be my characters for going through the indoor generators and adding sensible chest locations to each one. I thought about having a set of characteristics here, e.g. the “(” chest is always of a certain type or requires a certain description, but it soon became apparent that a) I was adding complexity for no good reason, and b) I could just easily have the game essentially do this on the fly for each grid. So, I’ve begun this process and while it’s not cognitively interesting, it’s not exactly demanding, and just takes a bit of time. This won’t take more than a few more hours to do all the indoor segments for 0.11, and then the game will know to always look for those four characters when trying to place a chest. The important thing twas to ensure that in each grid, these are placed in locations that would have different descriptions, according to the four things that they are orthogonally adjacent to – since that is what this part of the riddle generator uses to describe how a chest is placed. So, for instance, in one generator grid, I might have “(” next to one chair, “)” next to two chairs and a wall, “¬” next to one wall, and “_” next to three chairs. That then guarantees that whichever is picked a sensible description can be created, and it’ll be distinct from the others. This also enables fun things in the future, e.g. you enter a room with 16 chests in a 4×4 grid, say, and a layout of walls and chairs, and one of them is the one being referred to and the others are not (but are trapped!). I’ll also be able to extend this in other ways (again later, not for 0.11, need to stay focused and on track) e.g. directing you to a chest that is furthest from any statue in that room, for instance, or the chest that is furthest west, or the chest that visible from a certain location, etc etc. These can be expanded in some really fun ways, but for now, we have the game looking into the four tiles surrounding the chest, deriving a (very easy to understand, since it’s plain English) description from that, and then slotting that into the tutorial clue as required. Indeed, although I can’t use the “have the game look through the building and find good locations” system for the correct chest for the various reasons listed above, I actually would very easily be able to create such a function for filling up some buildings with lots of incorrect chests when the game demands it, and thus in doing so ensure that none of the false chests would generate the precise same description as the correct chest. Anyway, the point is that this is a good middle-ground of the options – a bit of labour, but not that much, and something which I can do bit by bit over a long period of time, and then a system which can place chests (or anything else, actually…) into locations in inside grids which are known to be distinct. For outside grids, well, I have another idea, but we’ll come to that later. The important thing is that this enables the game to place a chest in a building on campus, and create a description that correctly tells the player about the location of that chest, in which they find the final note, to return to the curator. And in the future, this functionality will allow all kinds of other stuff as well!
A big milestone
So, there we have it friends – a huge milestone has been reached. URR has its first quest! I’m just so pleased with the fact this actually works and brings together so many game systems to function correctly in however many millions of permutations it has (even for a simple tutorial thing like this), but also how effectively – I hope – it will get across the things it needs to get across. While the structure of this quest is not generated (it’s always an outside chest digging up first, and then an inside chest with the key), the content of this quest is entirely generated. Generating the structure is now something I have a clear idea how to do, however, and that’ll be the next thing for getting the initial non-tutorial quests for 0.11 successfully up and running; it’s a bit more complex, but not unreasonably so. I’m incredibly excited to delve into it, as te even bigger milestone, of course, will be the ability (VERY soon) to play a non-tutorial quest, and that’s a bigger milestone because the complexity is genuinely orders of magnitude higher – but this has shown me two essential things. I can get the same to generate a set of followable riddles in a generated set of places, and these can be logically and clearly solved. Beyond that, it’s all just a matter of scaling up :). I really think these are at the correct difficulty, too – I think they’re pretty trivial to solve, each tutorial thread only requires two steps (i.e. one pointing to digging outside a building, and then one pointing towards a specific chest inside another building) and both steps are about as clear as I can make them while still having something to solve. But, yes, the upshot is:
IT ACTUALLY WORKS.
Thanks for reading, everyone. As ever, please do leave your thoughts below, or share this around on the web if you think others might be interested. I’ll see you next fortnight probably for finishing off the new conversation system (for 0.11 at least), or further clue development, or quest development, or data infrastructure… not sure which, but the point is I’m working flat-out now for a release this year, and there’s really not much left to do. Hope you all have a lovely fourteen days, and I’ll see you all then…