Archive for June, 2012

More inventory trouble

2012-06-23

Still working on the new inventory interface. I have freed up two lines at the bottom to make more room for the description box. This leaves me with only one line for the key reference, but I think that will do.

I have hit a snag with item pickup and dropping. These actions are supposed to cost one turn per item, but this menu locks up the game logic flow. I can’t easily drop a single item, go back to the main loop to run a game turn and then resume the dialog. I have a few options, none of which is really good:

  • Create some kind of delayed event queue that drops items one by one. This is way out of scope. I never planned for it and there are just too many things that can go wrong. For example, items can be destroyed between turns so at the very least I would need a safe GUID handle for every item in the game (now I just have pointers).
  • Make a slightly hacky variant of the above with the “multiaction” facility. This is my current way of extending actions over several turns, but I think only resting and “Aimed Shot” make use of it so far. This for a reason – it’s a real mess to work with. I could possibly supply it with a list of item letters to pick up from the current location. If an item is not there (it has been removed or destroyed) it can simply be skipped, so there’s less risk of crashing.

From a gameplay point of view, my main complaint about these two is that they will lock the player up for several turns. If I try to pick up five items and an enemy wanders on screen, I want to interrupt and deal with that first. They also open up gray areas like what would happen if the player is teleported away during the extended action (should probably just abort the action, but I would need to track down every case where it can happen).

  • Pick up item, set a flag, return to the main loop, at the next turn (if the flag is set) return to the dialog. I think this would work but probably cause UI bugs (and I have enough of those already).
  • Make drop and pickup cost only one turn regardless of how many items are transferred.
  • Make drop and pickup free actions. This is how (un)equip works now: you can completely replace your equipment without even spending a turn.

The last two would keep drop and pickup as atomic actions, but would require me to change the ruleset. I do not want to make the actions entirely free since I wish to keep their tactical purpose – “should I stop to pick up and use that potion of healing or just keep fighting for two turns?”

Free dropping could throw the encumberance penalties off balance. I’m not happy with them anyway so this could be a good thing. If I decide to keep encumberance I could change it to some kind of delayed effect if necessary.

Allowing multiple item transfer in a single action would create some odd discrepancies in the UI. For example, the “do what I mean” Enter key only picks up one item at a time, while the ‘,’ key would let you pick up several. I could change Enter to pick up everything on the floor.

A compromise would be to only let the player transfer a limited number of items, say three per turn.

I’m probably overthinking this. You usually pick up only two or three items at a time and letting that consume only a single turn would not change much, and this issue will definitely not govern how fun the game is. I’m all for removing micromanagement and if anyone wishes to grind and scum that isn’t really my problem.

Oh, and another thing: I made so the default pickup key ‘,’ works within the pickup menu as well. You can now hit it once to bring the menu up, then keep tapping the same key (rather than Enter) to pick up the selected item. It feels much more natural, much more… dwim-y.

Advertisements

Introducing RUUKLOST

2012-06-21

This is another game I am working on. RUUKLOST is an attempt to replicate (and an homage to) NES-era platformers. As a spirit warrior of RUUKLOST, you travel through hostile wilderness and ancient ruins to collect the essence of your fallen brethren. The world will require thorough exploration and many areas remain inaccessible until you possess the appropriate abilities.

I am stalling at the moment since I lack sprites. I am not much of a pixel artist myself and it takes a lot of time to draw. If you feel like being lead artist and monster designer, let me know.

Current status:

  • Engine: Using the Allegro library so it is very portable. It already runs on Linux and Windows. Graphics are really 300×200 and scaled up to the window size (or fullscreen) the player prefers. Levels are tile-based and the backgrounds have parallax scrolling (one layer). It is designed for a gamepad but also works with a keyboard. Infrastructure is mostly in place but I have done little monster programming and quest scripting so far.
  • Level editor: Built into the engine, to build and playtest at the same time. Not very polished but almost complete and gets the job done.
  • Level design: About 10% done.
  • Grapics: I have about 1/3 of the tiles I think I need. I have player sprites and a few monsters but most are rather crude. Backgrounds are needed. Title screen and font done.
  • Music & sound: Not even started.

Resuming TSL development

2012-06-21

I have had a break from TSL development for a while (I have been working on RUUKLOST and some other things). I recently got back from the IRDC 2012 with a lot of ideas, so I have taken up development again.

The focus right now is fixing some of the interface issues. TSL, being a very conservative roguelike, is built around the “verb-object” interaction model – that is, you first decide what to do, then which entity to interact with.

A classic example of overly complex roguelike interaction (besides the “wipe ears” command) is having separate keys for going “up” and “down” stairs.

(As a bit of an aside: this is surprisingly one of the few “anti-features” I have avoided in TSL – since up and down stairs can not coexist on the same tile, I decided early on to just have a common key for both and I recently I dropped directional stairs entirely. My levels lack the concept of “depth” and have a somewhat non-linear progression, so up and down are meaningless. Stairs simply take you between levels – that’s it.)

Many players find the menus in TSL confusing and wish to navigate them using the arrow keys. They also ask for an easier way to perform “default” actions as it is not always clear what an item is capable of. I admit this is a problem. “Emergent item interaction” is a central concept in roguelikes and I have a few items with intentionally vague usage – however, these should not be off-putting for the whole game.

I am currently working on a “do what I mean” concept. I have already done some things in this area. Last year I made Enter a general-purpose DWIM key. It will, in highest to lowest priority:

  • Pick up an item at the players feet
  • Climb stairs (if there are no items)
  • Wait a turn (if there are no items or stairs)

There are still separate “pick up”, “climb” and “wait” keys. There are situations where you might want to wait on top of stairs or climb them without picking up items first, but most often you do not.

I also wrote an inventory system that could sort items by type, filter out “uninteresting” items (for example, only potions show up for the “drink” prompt), switch between items and allow common actions without leaving the menu. This was slightly more convenient than the old “inspect” command that would display two items side by side, but

This approach still fails to address the “verb-object” problem, explain which items support which actions or make the menu navigation easier – in fact, it adds even more keys!

So, for a couple of days, I have been making another attempt to resolve this:

You browse with the arrow keys or jump to an item by pressing its letter. The list auto-scrolls at the 2nd item from the top or bottom (the small cross at the bottom indicates you have more items than would fit on screen – I might replace the character but I like the discrete look).

At the bottom is a quick reference what actions you will take by pressing different keys:

  • Enter performs default action (drink for potions, read for scrolls and book, equip for equipment, remove for already equipped equipment, and so on)
  • A way to drop items (not sure if I can use the alphabetic default for this, since it would clash with the point below)
  • Alphabetic characters navigate to specific items

This is clearly a departure from my earlier assumption that every player is an expert in hardcore roguelikes and/or enjoys learning 20 keybindings from a help file. I hope to find a balance between “displaying helpful tips” and “wasting screen space by displaying text that no one will bother to read after their second play session” (I’m not keen on adding an option toggle for “novice” and “minimal” modes). I think two lines at the bottom should be enough for this.

It might also seem like a waste of space to have separating lines all over, but it really helps to keep things structured. If I absolutely need all 24 lines to display text, I would be displaying too much information anyway.

Verb-object interaction will still exist in parallell, but I honestly think most players will prefer the new mode.

Obviously this is a work in progress and still has rough edges. Text doesn’t wrap properly yet. The angle brackets around item names indicate which ones are currently equipped, but this should be made more prominent (right now I’m thinking of appending “(worn)” or maybe indenting the line – we will see).

I might also use the “flip” key (tab) somehow to display long descriptions (most items should have short descriptions but there is bound to be a few that need more than 30 words). This would either shrink the list and enlarge the description box, or scroll the description box.

I will also be using this menu for the facet/augmentation inspection and pick up item screens. When picking up items, the player would typically hit the ‘,’ (or ‘g’) key and press enter-enter-enter-enter to transfer each item to the inventory (they would then disappear from the pickup screen). This will also let the player inspect items before picking them up, which I think will be a welcome addition.

I’m not sure how well this will mesh with the turn model. Currently a turn is consumed for each item picked up. If I allow multi-item pickup on a single turn this is no problem, but if I want to run other game logic between each item without the player leaving the menu, it’s going to require a really serious and ugly hack.