Major Mid-September Update

This week’s blog entry is a big update on what I’ve been working on this week in the game, 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.

Water

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.

POisons

I’ve also remade the inventory (for the final time). The inventory in 0.3 is effectively a “fake” inventory – youInventory 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 on the left). 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, mInventoryeanwhile, 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:

TorchesTorches 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):

Inventory

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:

InventoryAnd 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.

Vision1

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.

Vision2

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 & Facebook for details…

Be Sociable, Share!

5 thoughts on “Major Mid-September Update

  1. I’ve thought about light and undiscovered areas in my project, too. Mostly I’ve been concerned with how to display enemies that are between you and a lit area. I recall that Pyromancer has some sort of a solution, in that it displays said enemies as question marks.

    Another way to get past the gameplay issue of displaying enemies in back-lit areas would be throw a number of ‘silhouettes’ around in the dark area for each enemy (or friend!), creating a strong incentive to manage lighting while still giving a taste of “realism”. As for displaying terrain, I think you’re on the right track.

    P.S. Who drops torches? They’re meant to be thrown around Indiana Jones -style.

  2. I don’t believe I’ve seen it mentioned before, but I’m curious to know how you’re drawing/designing your art (aside from the obvious procedural content). For my own projects I created an ASCII art program, and am wondering if you did something similar, or are relying on some other method such as an existing application or (ack!) scripting/hard coding everything.

    Nice unique style you’ve got there!

  3. @ Vodrilus – I did consider a system like that to reflect silhouettes in real life, and I think that’s a fine system, but I’ve decided not to do that. I think you’ll get more interesting gameplay if things simply cannot be seen between you and a light source, even if it is slightly less “realistic”. Thanks re: terrain, and re: torches, ah, well, throwing is one of the things I need to implement very soon! I’m going to be streaming coding tomorrow and/or Friday, and throwing might be one of the things I work on then.

    @ Kyzrati – I’m basically storing it as a grid of characters, so “abcde” as a string will then each be printed as a particular character with a foreground/background. Since there are far more variations of colour/character needed than possible even using every character a computer has to offer, I basically make each one “anew”, so each graphic has a different list of “a= [char], b = [char]”. I haven’t created a program for it, but it goes pretty quickly this way. I do sometimes use ASCII paint to throw around ideas though. And thanks!

    • Since you use a lot of art, and I expect there will be plenty more in the future (though I’m not sure how much non-procedural stuff you plan on introducing), you may want to consider the possibility of creating a tool to help out with that. You can be a lot more productive with the right tools.

      Somewhat surprised that you’re doing it all in code. It only took a couple weeks to put together the program I use, and it has/will save enormous amounts of time in the long run. (Not really wanting to advertise here, but it could be useful to you for prototyping purposes, since it’s made to be user-friendly and very flexible: http://rexpaint.blogspot.com. In fact, you could even use REXPaint and just import the files it creates; it was originally designed for roguelike devs to use for art. I’m also still adding features on request if there’s something you might need that would benefit other devs as well).

      • I have thought about producing a tool, but I decided in the end that it wouldn’t be worth the time (even thinking in the very long term). I’ve become very fast at my current system, actually, and I’m not sure how long it would take me to make a tool. However (no worries about advertising!) I will certainly give REXPaint a look : ). I’ll also think about potential other features, as you suggested…

Leave a Reply

Your email address will not be published. Required fields are marked *