Messages

1

Programming / Re: Do you use loops?

« on: May 25, 2016, 01:50:37 AM »

Ruby code usually uses the `each` method on collections instead of explicit loops.

Code: [Select]

items = ["sword", "shield", "armor"]

items.each do |item|
   puts item
end


2

7DRLs / Dungeon Of Cards [7DRL 2016] [success]

« on: March 13, 2016, 07:17:12 AM »

A collectable card game roguelike. Pick an adventurer, run around playing cards, fighting, finding amulets, and exiting the dungeon. Or dying.

Made in Unity so it should work on Mac, Windows, and Linux, but I'm not super sure about that.

7drl.org seems to be down so I can't update my progress there.

Repo at https://github.com/trystan/DungeonsOfCards
Download zipped binaries at https://github.com/trystan/DungeonsOfCards/tree/master/bin

3

Design / Re: Considering when to generate random map details, all at once or as needed?

« on: December 04, 2015, 02:43:11 AM »

One big advantage of doing it all at once is that it can be easier to guarantee things about the entire world, like connectivity or distribution of loot, at once. I also prefer to have the worldgen stuff in seperate code that only happens once.

The only major advantage to doing it one level at a time that I can think of is that you can create the next level or item based on the current situation. That is, you can do something like have a 10% chance of the next level being The Ice King's lair if the player has the Ice Crown, spawn a bunch of cursed loot if the player is unlucky, spawn a thief for each 100 gold the player has, etc.

I've tried both ways with 7DRLs and personal test projects and I find the all-at-once way easier to code and reason about. Maybe a mix where the levels are created first but the loot in treasure chests or boss drops are determined when needed based on the what the player is doing?

4

Design / Re: Nonstandard Attack Option

« on: December 04, 2015, 02:32:20 AM »

I have been considering starting on a new project and making another rogue. I've started many, completed one (ok, it didn't have a true ending, but complete as far as my goals are concerned), and I continue to run into the same problem. They fulfill a lot of the rogue check boxes (permadeath, proc gen levels, etc) but they just aren't fun. I tend to make things that are interesting to me, from a programmers perspective, but aren't near as interesting to a player.

Sounds good to me. I'm a big believer in prototyping something as quickly as possible and either throwing it away or iterating on it until I'm not sure how to improve it. Either way, you get better at programming, better at game design, and learn something new.

I want to give the player interesting options in combat and thought about giving him a rock, paper, scissors (RPS) kind of choice. Something like a attack, block, and a counterblock. Instead of these being distinct actions, I wanted to implement them all as a form of attack. It's just that block would do very minimal damage but would essentially negate that full attack option that the opponent uses.

I've had similar thoughts about how to make melee more interesting. One idea I like is from the board game Kemet (https://boardgamegeek.com/boardgame/127023/kemet). When a group of your warriors is in the same space as another's, you each secretly select an attack card and simultaneously reveal them. Whoever has the highest card strength + number of people, wins. But the cards also have a blood amount that kills enemy warriors and a shield that prevents your warriors from being killed. If all your people die then you lose the fight regardless of the strength of your army. So instead of having an explicit rock/paper/scissors, you have to try and figure out and counter the opponent's strategy. Do you play your highest strength card and try to win without much carnage, or do you go for maximum blood and hope they don't use shields and you can kill them all and win, or do you go for moderate values in all three and hope to win? You and your opponent can't replay your cards until you go through all 6 of your cards so what you play now affects future battles too. The upgrades and secret cards you can play add to the basic strategy. I'm not sure how to translate that into what you're trying to do, but it may inspire something.

I also understand that interface seems like a problem with making it streamlined without many controls. Idea's here would be great too. Start from an interface like the original rogue is what I'm hoping and modify it, but there may be better alternatives(?).

My only advice here is to start with a minimal interface to a minimal roguelike - such as an @ on a hard-coded level with a few enemies that randomly move about. No start screen, no inventory, maybe not even messages. Then try one idea for attack options. Set it aside and try another one. Set that aside and try something else. As long as you only focus on the nonstandard attack option - forget food, xp, items, unique creatures, win conditions, etc - you can try a lot of things and come up with some cool stuff. A few duds, but a few cool things too. Then you can pick one and add other features that complement the main idea of non standard attack options without cluttering the ui or confusing the player. The roguelikes that get attention and do interesting things tend to be either giant games with decades of people working on them or games that focus on one idea, explore it as much as possible, and push it to the limits.

I'm sure a lot of us would like to see what you come up with.

5

Design / Re: Simple AI/Logic for chosing enemy skills?

« on: June 14, 2015, 07:36:24 AM »

It depends on how you program it, but one thing I've found useful is if each actor/creature/whatever asks each ability that it has "what should I do and how likely should i do it?". Each ability would answer with something that has a callback function and how important it is that the action happens.

So if a creature has a heal spell, the chance of it being called might be "100% - current_hp / total_hp". So the lower the current hp, the more likely the heal spell is chosen as the current action. The callback function would be something that heals the caster. The code for the ai of a healing spell (in a javascript-ish language) might like like:

function doAi(caster) {
  return {
    chance: caster.hp /caster.maxHp,
    callback: function() {
      caster.hp = Math.min(caster.maxHp, caster.hp + 10);
    }
  }
}

Then the creature's ai would decide each action to take based on the chances, then call the appropriate callback function. The ai might choose the most likely action, or do a lottery type system, or add a bit of randomness. Even movement could be included as an action in this system.

My previous 7DRL from 2013 (which you can play or watch it play itself in your browser at http://trystans.blogspot.com/2013/09/pugnacious-wizards-2-version-10.html) does this.
See https://github.com/trystan/PugnaciousWizards2/blob/master/src/EnemyWizard.as#L36 for the caster's ai
See https://github.com/trystan/PugnaciousWizards2/blob/master/src/spells/HealAndWeaken.as#L25 for one of the healing spells.

6

Design / Re: Thoughts on this identification system idea?

« on: April 28, 2015, 02:25:25 AM »

I like your idea of groups but what if instead of just being groups of explicit potions, the group is another modifier?

They could be tiered (such as: inferior, lesser, common, greater, superior) where "better" ones tend to be in the better tier or just different adjectives (such as: glowing, foggy, glittering, bubbling, thick). Or maybe both? So once you know what "glowing" potions are, you can narrow down what the "glowing red" potion is.

You could then give each group a subtle theme. Maybe "foggy" potions are all harsh tradeoffs (heal but become poisoned and slowed, increase stats but drop all items, etc), "thick" potions will affect the senses (blindness, detect curse, etc), "bubbling" affect terrain (target and surroundings catch on fire, smoke covers target and surroundings, etc), and so on.

You could even tweak the randomness: with no randomness the "glowing" potions are always healing, acid, see invisible, stone skin, and anti-poison, with low randomness one of each category is shuffled into another category, with full randomness there's no telling what the "glowing" potions are.

I can image being trapped in a corner with 1HP, three enemy orcs, and a bunch of unidentified potions. I don't know what they are, but I know the general type of effect. Should I risk everything and drink or throw a "superior foggy" potion, or try for a possibly safer aoe effect with a "common bubbling" potion?

7

Programming / Re: Quick changes, Huge improvements

« on: April 14, 2015, 02:26:28 AM »

Good stories.

1. Log to the screen: I'm sure I'm not the only one who has a few print statements in the tricky parts of their ai code. One thing I did years ago was start writing it to the screen as a message (if the player was in sight) instead of to a log file. So by changing

Code: [Select]

Debug.log("Low health: " + creature.name + " eat " + food.name)to

Code: [Select]

creature.doAction("eats " + food.name + " and looks better.")it became easier and far more interesting to see what my creatures were up to and why. The world was much more interesting once I saw what was going on and that tiny change made a huge impact to the feel of the game.

2. Use maps (dictionaries, hashes, associative arrays, etc) instead of 1D or 2D arrays: I used to store items and creatures in an array or list and iterate over them when I wanted to know if one was in a specific location. I tried using a map of position to item one day and it worked. It worked really well and the code for lookups was much cleaner, the performance was better (not that it mattered really), and modeling it this way seemed like a better "fit".

8

Programming / Re: Cached Supercover Field of View algorithm

« on: March 25, 2015, 03:39:34 PM »

Have you actually implemented this?

I've thought of something very similar but don't remember why I gave up on it. I assume others have thought of it too. So why isn't this used everywhere? I'm guessing it doesn't work quite right for some reason but I'd like to be proven wrong - a better FOV algorithm that's easier to understand and implement benefits everyone.

9

Programming / Re: Programming graphical effects with delays

« on: March 20, 2015, 12:30:54 AM »

What I've done a couple times is have different queues that animations and effects can go in. Then, during the timer callback, if there's anything in the first queue, update them and refresh, else if anything is in the second queue, update them and refresh, etc. If all the queues are empty and the player has taken their turn, update the monsters and let the player take their next turn. I can put visual effects in the first queue, projectile effects in the second queue, and creatures being knocked back in a third queue. So far it's been simple, flexible, and easy to use and understand.

10

7DRLs / RUNNER_PUNCHER (7DRL 2015) success

« on: March 17, 2015, 03:03:16 AM »

I finished my 5th 7DRL on Saturday and thought people here might like to see it.



Bullet points:

• RUNNER: You start with 5 moves for every 1 move everyone else gets.
• PUNCHER: You start with an attack that knocks others back 5 spaces.
• RANDOM ENEMIES: Theres a list of 8 prefixes and 8 postfixes that are shuffled together each game (like the board game Small World).
• RANDOM ITEMS: Smelly boots, Cape of life, knuckles of punching, boots of webwalking, etc. Mostly crap.
• DENSITY: Only 5 levels packed with items and enemies.

Clojure code and jar file can found at https://github.com/trystan/runner-puncher/releases

11

Programming / Re: Dataflow programming in roguelikes, exploring Field of view calculation

« on: March 14, 2015, 04:20:23 PM »

What?

Is this implemented somewhere?

I've also thought about other ways to do FOV. One way that I think sounds like what your describing is to precalculate what are 'behind' each tile (where the viewer is at (0,0)) then do something like your PerimeterMarch function. If a tile is blocked, then skip it, otherwise add the tiles 'behind' it to the new perimeter tiles. Repeat until your set of perimeter tiles is empty.

So if (1,0) is blocked, then don't bother with (2,0) but if it's not blocked, add (2,0) to your perimeter set.

I don't remember why I haven't tried it yet though. I think because the naive way has always worked well enough for me.

12

Player's Plaza / Re: RLs and strategy

« on: March 13, 2015, 06:03:39 AM »

I'm pretty sure poker has a lot of strategy but even the worlds best poker players don't win every hand. Over the long run they tend to win more than worse players though.

I think roguelikes are similar. You have to know how to calculate the odds, make the right gambles, and know how much to commit to each encounter. You still might lose, but after a few hundred attempts, you'll lose later and less often.

Although some roguelikes are beaten every time by bots or experienced players.

I never get very far in any roguelike I've played so I could be very wrong.

13

Programming / Re: Preferred screen size?

« on: March 11, 2015, 06:14:43 AM »

I ended up letting the user override the default window and font size by command line switches. Took about 60 minutes. Totally worth it.

It defaults to a 1280x720 window or smaller based on your screen size with a 10x10 font.

14

Programming / Re: Preferred screen size?

« on: March 10, 2015, 04:21:51 PM »

Thanks for all the great replies everyone.

Is it too much trouble to allow for different font choices? Really the implementation depends on your individual game, though. As Omnivore says, cell size and viewport have a significant impact on both gameplay and workload.

True, but for a 7DRL written from scratch in a language I'm still learning, yes it is too much. But I think I will switch to 16:9 ratio.

OP: If stats are what you're after in order to cater to the majority of what's out there, the chart on this page is very informative. Basically more than 80% of players out there use a widescreen resolution. Last year I wrote an analysis of my own font decisions based on that, with lots of examples if you're interested. Actually, now that I check the link the more general Fonts in Roguelikes post would be an appropriate read, too.

Perfect, that's a great post and really helpful.

Part of why we can't really give specific good advice to the OP is he didn't give us any information about the roguelike in question. Hard to say if we're even being helpful here without more input

Here's the game I'm working on this year: http://7drl.org/tag/runner_puncher. There's a screenshot with 8x8 and 10x10 font size.

15

Programming / Preferred screen size?

« on: March 09, 2015, 11:01:29 PM »

What's a good screen size for a roguelike? What works well with youtube reviews? I know using the terminal directly means the user can change the size to what they want but I'm asking about tiles or emulated terminal.

I think the "old school" terminal style is a 640x480 window with 9x16 tiles.

My current 7DRL is 640x480 with 10x10 tiles and seems ok. One of my previous 7DRL was 600x600 with 8x8 tiles and looked terrible on youtube due to resizing and some people said it was too small.

So what actually works well?