Messages

76

Programming / Re: Handling a large number of actors

« on: December 09, 2013, 12:28:55 PM »

For your actor energy system, use this (or reference the other Basin articles on the same topic). It's a really fast method that doesn't require repeated sorting. This may be more or less what you're already doing? In any case, if a program is slow and you want to know why, profile it. Once you fix whatever the bottleneck is it'll definitely be faster than what you've got now. Try not to optimize before profiling--you'll probably end up wasting a lot of time.

I just want to say I agree wholeheartedly with this. Always profile and optimize the bottlenecks. The problem could be very far from what you think.

77

Traditional Roguelikes (Turn Based) / Re: Infra Arcana v15.0

« on: December 01, 2013, 03:11:23 PM »

-Perhaps an option to Mute audio would be a better solution than just disabling it outright in terms of it needing to reload the entire batch from a full-on to off.

An in-game button to mute the audio would be good. Although I think an option to unload it completely is nice too, if you want the game to be more lightweight and not allocate memory for the audio.

-Font scale 2x option only seems to work with one font?  Can't even toggle the rest.

The thing with the font scaling is that if you play in tile mode, the font size needs to match the tile size. So yeah, the only font you can scale up then is the 8x16 dos-like font, to be displayed in 16x24 so you can use it in tiles mode. If you play in ASCII mode, any font can be scaled.

78

Traditional Roguelikes (Turn Based) / Infra Arcana v15.0

« on: November 26, 2013, 10:22:31 PM »

v15.0 is released!

infraarcana.wikispaces.com/

The highlight is that sound effects are now added to the game, but there's many other interesting updates as well.

Changes:
* Added sound effects (for weapons, monsters, etc) and atmospheric ambient background sounds. Audio can be enabled/disabled in the options menu.
* The track “Madness” by Musica Cthulhiana (from the album “Fragment”) is used as intro music in the main menu
* Reworked the status effects system, and changed/added many effects. Internally, status effects are now called “Properties”. They can describe both a creature’s temporary conditions (confused, burning, diseased...) and permanent attributes (natural fire resistance, light sensitivity...). It is now also possible for items to apply properties on the wearer. Properties may prevent damage (e.g. fire resistance will prevent all fire damage).
* Removed the physical/mental status resistances (measured in percent). The reason is that they felt too dependant on luck - you could for example get confused many times even with high resistance. Now there are instead binary resistances (you are either completely immune, or completely susceptible), such as resistance to fear, confusion, sleep, etc. The “shock resistance” percentage is still kept however, since this simply reduces shock by a certain percent (no luck involved).
* Changed the spell casting system to use a mana-like resource called “Spirit”, instead of the previous chance-based system. The reason for this is similar to the reason for removing physical/mental status resistances (mentioned above) - it was too unpredictable and luck dependant. Now it should be easier to make tactical decisions about spell casting.
* Being Confused now prevents spell casting
* All creatures have a certain amount of Spirit. If a creature’s Spirit is depleted, it dies (monsters may sometimes attempt to cast a spell that could kill it, if it “feels desperate”).
* Removed “Potion of the Cobra” (gave perfect aiming and dodging)
* Added “Potion of Frenzy” - Gives the property “Frenzied”: Perfect melee aiming, cannot cast spells or read, resistance to confusion/sleep/fear/weakening, attempting to walk in any direction will cause you to step towards nearest visible monster, becomes weakened when effect ends.
* Added “Potion of Spirit” - Restores spirit
* Added “Potion of Fire Resistance”
* Added “Potion of Insulation” - Electricity resistance
* Added “Potion of Antidote” - Cures poisoning
* Removed “Manuscript of Identify”
* Renamed “Potion of Knowledge” to “Potion of Insight” - It now identifies a random carried item, as well as increasing Mythos knowledge like in previous versions
* Changed “Manuscript of Descent” to a potion
* Added “Manuscript of Sacrifice Life Force” - Convert remaining Hit Points to Spirit points
* Added “Manuscript of Sacrifice Spirit” - Convert remaining Spirit points to Hit Points
* The spell that you gain after reaching a certain level of Mythos knowledge (“Thaumaturgic Alteration”), now chooses effect automatically (instead of player selecting the effect from a menu), this can include a random manuscript-spell, or a special effect if the circumstances allow it.
* Renamed the spell “Azathoths Blast” to “Azathoths Wrath”
* Added armor “Asbestos Suit” - Wearing this gives you resistance to fire/acid/electricity. It has 1 armor point (physical damage protection and durability of the armor)
* Added armor “Heavy Coat” - Wearing this gives you resistance to cold. It has 1 armor point
* Bloated Corpse spit attack now does acid damage
* Added a few cold based monsters that does cold damage
* Hit points now automatically regenerates over time, although you can receive wounds that need many turns of active healing (similar to how HP were healed in previous versions, but more elaborate - see below). Each wound reduces your fighting abilities (especially melee) and your HP regeneration rate. If you have more than four wounds, you die.
* Added item “Medical Bag”. This has a number of different uses, the main purpose is to heal wounds.
* The [h]eal command has been removed, instead you use the Medical Bag.
* When attacking ethereal monsters (e.g. Ghosts-type monsters), the attack will often fail to hit (“My attack passes right through the Ghost!”). In case of ranged attacks, the projectile will often pass through the monster and continue on its path, even if aiming succeeded.
* Shadow-type monsters are now light sensitive - they are harmed each turn a light shines on them (e.g. from a lantern, flare, or burning creature).
* Reworked leveling system: You now pick all your character’s traits and skills at the start of the game instead of when gaining levels. Gaining a level now increases your hit points, and for some levels also attack skills, dodging, spirit points and mythos knowledge.
* Merged/changed/added some traits and skills
* The formulas determining XP needed per level, and XP given per monster are completely remade.
* A monster’s chance of spotting you is now affected by distance.
* Added fountains that you can drink from for various effects
* Some dungeon features can now spawn more freely on the map, as well as in themed rooms. Some room themes are also made less obvious now, and their label has been removed from the bottom of the screen. The reason for this is that in the previous version some themed rooms got very repetitive (e.g. too many levels had identical human quarters with a chest, cabinet, and some Cultists).
* Added a simple animated effect for summoned monsters and for creatures hit by spells
* You no longer automatically reload your weapon when attempting to fire an empty gun (though there is a setting in the options menu to enable this again). The reason is that it was too easy to reload by accident.
* Fixed a typo that said “Press ‘v’” when you tried to throw a missile with empty missile slot. Changed it to say “Press ‘w’”, which is the actual command to equip items.
* Fixed a bug that prevented you from using melee attacks on a turn that you had a free move from the “Dextrous” bonus, and walked in liquid
* Fixed a bug where carrying multiple electric lanterns prevented you from using any other than the top one

Enjoy!

79

Player's Plaza / Re: What trait disqualifies a game from being a rogue-like.

« on: November 21, 2013, 01:42:43 PM »

Have either of you seen Kerkerkruip? It's an IF roguelike, and it's pretty neat. There's definitely a lot more (and a lot of different stuff) that could be done with the idea.

Interesting. Thanks for the tip.

80

Design / Re: Robot roguelike?

« on: November 20, 2013, 08:26:23 PM »

Heat levels in different parts of the robot could be used to limit usage of stuff like firing lasers. It would literally be a cooldown system

81

Player's Plaza / Re: What trait disqualifies a game from being a rogue-like.

« on: November 20, 2013, 07:17:41 PM »

Interactive fiction roguelike? That would be amazing if you could pull it off.  I've been thinking about working IF elements into a roguelike, specifically procedurally generated room/item/monster descriptions.

Something like that yeah

82

Player's Plaza / Re: What trait disqualifies a game from being a rogue-like.

« on: November 20, 2013, 06:13:25 PM »

If I see too advanced graphics, it just makes me think "I wish that effort were put in the gameplay instead". Almost total focus on the programming aspects of the game design is a huge part of the appeal of roguelikes for me.

But time spent on the graphics doesn't necessarily mean that time was taken from the programming. The people who made the graphics could be people who just do graphics and don't even know how to program.

I had this in mind as well. But I just can't imagine Nethack with Diablo 3 graphics Or Dwarf Fortress with Starcraft 2 graphics happening any time soon. (Yeah those are extreme examples, but I hope they show what I mean)

83

Player's Plaza / Re: What trait disqualifies a game from being a rogue-like.

« on: November 20, 2013, 02:59:22 PM »

Those first five are turn-based tactical adventure games with heavily randomized content and no persistent saves.

The last three are not.

Yes.

But I would also like to include something about style. For me, primitive graphics in favor of deep gameplay is one of the fundamental things I associate with roguelikes. If I see too advanced graphics, it just makes me think "I wish that effort were put in the gameplay instead". Almost total focus on the programming aspects of the game design is a huge part of the appeal of roguelikes for me.

I have even been thinking lately about making a completely text based game.

84

Player's Plaza / Re: What trait disqualifies a game from being a rogue-like.

« on: November 20, 2013, 08:09:18 AM »

Maybe it's impossible and senseless to state exactly what defines a roguelike.

But I easily know one when I see one.

These are roguelikes:
http://www.metalhead.ws/images/nethack-wiz-29.jpg
http://erapert.files.wordpress.com/2010/01/adom.gif
http://www.retrobits.net/palmos/images/angband4.png
http://i1.ytimg.com/vi/yReGKEBvCqQ/maxresdefault.jpg
http://crawl.develz.org/wordpress/wp-content/uploads/2010/11/tiles_screenshot_storm_disc.png

These are not roguelikes:
http://pcmedia.gamespy.com/pc/image/article/122/1226095/ftl-faster-than-light-20120915014330855-000.jpg
http://www.debugdesign.com/wp-content/uploads/2013/04/rogue-legacy.jpg
http://www.headupgames.com/shop/administrator/upload/screens/150/The_Binding_of_Isaac_05.jpg

85

Programming / Re: Realism in Roguelikes

« on: November 14, 2013, 09:44:01 AM »

My point is that my idea of realism is not tied to how detailed the game is.

For me, realism is something more like:
* The game's features are consistent with the setting.
* The game's mechanics, text, AI, etc does what you'd expect, based on reality. This reality may be modified to allow magic, elves, zombies, etc, it can still be realistic within that premise, and must still behave like you'd expect a world with elves to behave (I cringe every time I hear the argument "the game has elves and magic, don't complain that it's unrealistic that you can eat an apple to instantly heal all your wounds")
* Features should primarily be added to enhance immersion in the game world, not to add abstract gamey little mechanics. If you add dynamite, it should be because it would make sense that the game world has dynamite, not because you want to add an area of effect attack.

I'm mostly concerned with immersion and atmosphere.

If I take my own game Infra Arcana as example. Imagine I add gold coin items, and put shops where friendly cultists sell you items for gold. From a purely game-mechanical perspective, it would be a fun mechanic. But it would be ridiculous and unrealistic - in the sense that it would break immersion. Sure, the game is all about unnatural monsters and magic... but that's a completely different thing. I try to create a virtual world with the premise that there are unnatural monsters and magic. I don't need detailed simulation to do that, but I need consistency and a heavier focus on immersion than abstract mechanics.
As for detail, I just try to keep it as simple as possible (to develop and for the player) to convey the things I want.

With that said, I'm really fascinated by high detail simulation-oriented games like Dwarf Fortress, Aurora, Cataclysm DDA, etc. It's a noble pursuit

86

Programming / Re: Realism in Roguelikes

« on: November 13, 2013, 11:04:44 AM »

I think you shouldn't confuse realism with detail and complexity.

You could have a perfectly realistic game about a fight between two swordsmen of equal skill. If the whole fight is decided by a coin toss, this is totally abstracted, yet completely realistic.

Abstraction (lack of detail), can just as well support realism. For example the early days D&D hit points do this - they represent wounds, stance, stamina, fighting spirit, etc. It's highly abstract, but it's believable I think.

As for detail, complexity and simulation. Humans (mammals) are so complicated machines (to humans), and hard to simulate in a Roguelike without Dwarf Fortress level of dedication. What if we have a Roguelike only about robots? Still very complicated, but far more plausible to get a decent simulation of. Many of the traits could be expressed as SI-units.

87

Programming / Re: Procedural content generation and unit testing

« on: November 07, 2013, 05:50:13 PM »

@Kevin Granade & jlund3:
Storing the seed for later verification of a failed test definitely sounds better than using a fixed list of seeds! I'll cover far more cases, and I won't have the trouble like I described in (2).

I'll go ahead and make map generation tests in this way.

For example, the most common implementation of the twister (MT19937) has a state space of 2^19937 - 1, which is roughly 4.3x10^66207. Note that the number of atoms in the observable universe is estimated at around 10^80.

This made me laugh

88

Programming / Re: Procedural content generation and unit testing

« on: November 07, 2013, 03:39:02 PM »

By the way, for unit tests it is good to have a completely predictable RNG, not only use a constant seed. I mean whenever you ask your RNG to produce a number from 1 to 10, you must be absolutely sure that it will return 1 (or some other number, but you should always know what it will be).

Hm, I can't grasp how one would achieve this. If I have a method I want to test, which does 4 RNG calls, how would I predetermine those values? I suppose I could do some sort of mock-RNG, and provide it with a list of values, which it will just return the first value from on the first call, the second value on the next call, etc. Is this typically how you do this? It seems very fragile - if the order of the RNG calls change, or if calls are added or removed, the tests will break.

I suppose you could separate deterministic code from non-deterministic as much as possible, and only unit test the former.

If I have a function which should transform a room (make it plus-shaped, or put pillars inside etc), then I could split it in two functions - one which picks random parameters, and another which takes those parameters as arguments and transforms the room in a deterministic way. Then I need to run tests on the deterministic function that covers the necessary cases.
Verification of valid wall placement etc should probably be as much as possible in the deterministic function. The other function should just provide random parameters without considering anything (for example it could give how wide the plus shape should be, in percent of the total room width). Agreed?

89

Programming / Procedural content generation and unit testing

« on: November 07, 2013, 09:58:13 AM »

Hello

I'm in the process of adding unit tests to my game. I'm somewhat new to writing unit tests, and I'm doing it partly for the learning.

At first I started thinking that this will be damn handy for testing the map generation code (by far the hardest and least predictable part I'd say).

One example: generate a big number of levels and check that there's a path from the player to the stairs in each one (this is probably outside the scope of what a unit test should do, but... I want to test this anyway ).

The problem with this is that the tests will not be deterministic. Results will vary between runs. A successful test will not be reliable, and a failed test will be hard to recreate.

To solve this, I suppose you could specify the seed of the RNG (random number generator). Something like this pseudo code:

Code: [Select]

for(int i = 0; i < 1000; i++) {
  rng.seed(i);
  level = makeDungeonLevel();
  runTestsOnLevel(level);
}
This should at least make the tests deterministic.

However I see two problems with this:
(1) You will only test some cases - although maybe a thousand levels is more than enough...
(2) You may set yourself up for a lot of confusion. Suppose your level generation process makes 20 calls to the RNG. So with a fixed seed, those 20 calls will always be the same - all your tests succeed every time, everything seems to work fine. Now suppose after the 5th call to the RNG, you insert another RNG call for a tiny change to the level generation. Then wouldn't RNG call number 6, 7, 8 etc get new values? So you have significantly altered the way the level is created, even with this tiny change. Suppose now that this new level, which was never tested before, breaks the tests. Wouldn't you assume that your change broke the level generation code somehow? But in reality, it was already broken, it just happened to never generate a broken version until now. Perhaps like in (1), this is not a problem if you generate a sufficiently large number of maps.

I also have a question about the code example above, where I use 0 to 999 as seed. Is there any harm in using this series of numbers (the "first" 1000 integers, in a straight row) ? Would I cover more varied scenarios if I use bigger steps in the seed? Or use more "wild" numbers - not a straight series, but something like 39903 28495 391, 394874, 3233, 10824, etc...? I'm thinking that with a good RNG, just using 0 to 999 should be fine, and create varied results. I'm using Mersenne twister, which is supposed to be very high quality.

90

Programming / Re: "Game time"

« on: October 17, 2013, 06:52:43 AM »

Why not use units that are immediately understandable to the player, like milliseconds, rather than made up ones, like "ticks?"

I can smell a strawman. Ticks are a useful abstraction for designing and programming games with fine-grained timing.  This is standard practice when making real-time games. They don't have to be a round number of milliseconds. A developer can use them without exposing them to the player.

In my game I have "atomic turns" and "standard turns". A standard turn consists of several atomic turns. Most monsters, including the player, acts once per standard turn. The fastest monsters acts every atomic turn. The slowest monsters waits more than one standard turn - but not necessarily an even number of standard turns, it's rather X standard turns + Y atomic turns.

Some things are updated on atomic turns, for example which cells have light on them - to ensure this is always updated even from the perspective of the fastest monsters.