Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Topics - NON

Pages: [1]
Design / Wound system
« on: April 28, 2014, 08:26:57 AM »
I have an idea for a new wound system that I'd like to see your opinions on. This is intended for my game Infra Arcana, but could be applicable for most roguelikes.

In the current version of IA, a wound is received when you take a hit that does at least 6 damage. As Vanguard pointed out in this thread, this system can seem like you are being randomly penalized. I can agree with this. I suspect it would work better in a pen-and-paper RPG, where you roll the dice yourself and clearly see when and why wounds are happening.

If the idea explained below seems fun and solid, I would remove the "Wound" status effect from IA.

You have your regular cur/max HP:

Now I was thinking that "critical" wounds could have the effect of lowering your maximum HP. For example you might have critical wounds corresponding to 2 HP. This could be represented in the interface like cur/max/potential HP:

Your HP will regenerate naturally over time, up to the current maximum HP. To heal your critical wounds and raise your max HP to the potential max HP, you need to spend many turns healing, consuming medical supplies.

When should critical wounds be received? What I'm concidering is that this happens when you take damage while your HP is below 50% of maximum. For each HP lost below 50%, your max HP is also reduced by one.

For example:
You are at 10/20/20 HP. You take 4 damage. You are now at 6/16/20 HP. You have 4 HP worth of critical wounds.

Another example:
You are at 18/20/20 HP. You take 3 damage. You are now at 15/20/20 HP. No critical wounds was received in this case.

Yet another example:
You are at 12/20/20 HP. You take 4 damage. You are now at 8/18/20 HP. You have 2 HP worth of critical wounds.

This should make it much easier to see exactly when and why this is happening right? No hidden randomized numbers. You know that below 50% is the "danger zone".

It also makes (at least some) logical sense since HP is usually viewed as your general fighting ability, fatigue, and minor wounds, bruises, and sprains. Low HP would then mean that you are no longer in top fighting condition, and is unable to "ward off" attacks.

What do you think about this idea? Is there some game/roguelike that does something similar to this?

An alternative presentation could be cur/max(potential) HP, for example:
Maybe it's clearer.

Edit: If this system is too harsh, it could be tuned for example by halving the critical wound rate. For example if you lose 4 HP, your max HP is only reduced by 2. (This could also be implemented as Traits you can pick when gaining levels).

Programming / Multithreading
« on: March 26, 2014, 10:02:13 AM »
I'm doing a project to get some experience about multithreading (which I know very little about). For this I'm making a game that will play a bit like Dwarf Fortress. I'm thinking this should be a good type of game for this. I've seen discussions about using multithreading for DF and how it would benefit that game, since it tends to become really slow with lots of creatures moving around.

I have some basic stuff set up in a common single thread already (game loop, rendering actors, some utility functions, etc). The first draft will just be a benchmark demo, probably not even handling user input. I want to see what the limit is for map size and number of actors moving around with pathfinding, and how far I can push that limit with more effective algorithms and (hopefully) by using multithreading.

I do have a clear idea of a game I want to make from this though. I think what I have in mind would be an awesome game, so I'm excited about that too, and I don't intend to stop at just a technical demo. Of course I'm not going for something so huge as DF(!), this would be a much simpler game. Hopefully it can be a fun challenge.

I came here to ask for some advice about multithreading. In a game similar to DF, what would be good to put in separate threads? My first idea was "pathfinding of course", it's one of the most CPU-intense parts for sure. But can it be run in parallel with the rest of the game? It doesn't seem so - you calculate this before a creature moves. I guess when the time comes for calculating paths for all creatures, you could calculate as many paths as possible in parallel though. I'm also looking at bidirectional A* pathfinding - wouldn't that benefit from running in two threads? One thread would search from the origin and the other from the goal.

Would be interesting to hear your ideas. What could/should be put in separate threads? Would there be a lot to gain from all this?

Programming / Infra Arcana map generation demo
« on: December 19, 2013, 09:27:08 AM »
I did some videos to show the map generation process of Infra Arcana. Maybe someone here is interested in this :)

It's a pretty simple Rogue-style 3x3 map, with some extra stuff added to it.

Design / First person narrative
« on: December 10, 2013, 03:11:03 PM »
I'd like to hear your opinions on first person vs second person perspective in log messages.

For more than a year now, the narrative in Infra Arcana has been in first person - "I hear a growling voice!(NE)". The idea was that this would increase immersion, by putting you in the main character's perspective.

However I've started to doubt it. It feels weird that the player character is talking to the player about himself. For some reason it's easier for me to accept that the game is talking to the player (second person perspective).

Also, second person has more "classic" roguelike feeling, which is a strong argument for me.

What do you think of this?

If you play Infra Arcana, would you be upset if I changed to second person perspective? :P

Edit: I mean "second person perspective", not "third" - thanks George.

The topic was briefly discussed in some episode of Roguelike radio, I think it was this one:

Programming / Procedural content generation and unit testing
« on: November 07, 2013, 09:58:13 AM »

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 :P).

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++) {
  level = makeDungeonLevel();
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.

Programming / Method for ambush AI?
« on: November 23, 2012, 03:31:22 PM »
I was doing some idle thinking about making the AI set up ambushes for the player. I wrote up some possible steps for how to achieve this, as a starting point for discussion. It is certainly not intended as a "tutorial" or something.

* Do you think the steps below is a viable way to achieve it? (Implementation, execution speed and result)
* Are there better/simpler ways?

The scenario: There's a group of monsters that due to some AI choice decides they want to set up an ambush (they are aware of the player coming). I assume the game's AI is capable of telling them to go to a specified position and wait there until further notice.

A) Identify suitable position for '1' (pre-ambush position) and '2' (attack position). This step could be a whole point of discussion in itself, but assume we can identify a corridor shape leading into a room.
.......21    @

B) Run FOV from '1'

C) Run FOV from '2'

D) Find positions reached by FOV '2', but not by '1'

E) If monsters have (prefer) ranged attacks, remove positions in melee range of '2'.
Otherwise (if they prefer melee), remove cells NOT in melee range of '2' (though this example would only leave two such cells).
Sort the remaining cells according to distance from '2'. Start with the furthest cell and place a monster there. For the next position, if it blocks LOS from any previous position, earase it, otherwise place a monster there. Repeat until no more monsters or no more positions (if there are more monsters than positions, it needs to be decided what to do with the remaining monsters)

Programming / Weapon durability
« on: June 16, 2012, 12:54:45 PM »
I'd like to hear peoples thoughts on weapon durability.

I want to implement weapon breaking in Infra Arcana to add to the risk and fear, and also to make weapons a more valuable thing to find.

But I want to be careful not to make it annoying (as this feature can certainly be).

What do you think about having every hit degrade the weapon a bit?

Say that you have an Axe + 2 (does 2 extra damage), and it has a current durability of 3000 (this value is not shown to the player). Every attack removes a few points from the durability (say 1d3). Some events like a critical miss (you fumble and hit a wall) removes a bigger value, and worst of all would be to attack something like an acid ooze. When durability drops below 2000 the weapon is now only an Axe +1. Below 1000 it has normal damage. Below 0 it has -1 dmg. Below -1000 it breaks completely.

Edit: Weapon related skills could reduce the durability losses

Other Announcements / Infra Arcana interview
« on: May 18, 2012, 01:09:53 PM »
If anyone's interested, here's an email interview I did for Infra Arcana for a site called Pixelgush:

Programming / Opium, whiskey, insanity
« on: May 09, 2012, 09:09:31 AM »
I'm considering implementing drugs/alcohol to stave off insanity in Infra Arcana.

Would be cool to hear some ideas how it could work, what the penalties could be (addiction should of course be a risk).

I'm thinking it should reduce the long-term insanity for a cost of temporarily lowering your aiming/dodging/searching/whatever. And every time you use it, a variable counts up (invisible to the player, except maybe some occasional message when it gets above certain levels). The higher this number is, the higher chance for getting an addiction every time you use it.

Addictions would be a "thing" similar to phobias and compulsions. A pop-up appears telling you that you have it. For alcohol for example, you could have increased shock rate and terrible aim (shaky hands) when you don't drink :D

Give ideas please

Programming / Bug tracking?
« on: February 10, 2012, 10:21:31 PM »
Can someone recommend a free bug/issue tracker?

I think this would make life a lot easier in the hypothetical case of continued IA development.

I'd prefer if it was completely online if such a thing is possible. No downloading and installing anything.

Programming / Automated testing
« on: September 01, 2011, 10:53:05 AM »
I've found myself creating bugs in my game lately, caused by dumb little oversights in the code.
For example:
Code: [Select]
if(OTHER_IS_AWARE == true) isBackStab = true;when It should clearly be
Code: [Select]
if(OTHER_IS_AWARE == false) isBackStab = true;
It's often trivial to find such misstakes, but it sucks when I discover it after a release.

I wonder how others deal with this. How do you prevent it? Do you have automated testing?

I did some reading on unit testing, but it seems like overkill for a one-man roguelike project, and I don't really have the time to implement it.

One idea I have is to have the game print lots of info to a file by using cout. Then I have a separate program that reads the stdout.txt file. It can check for example how many points the player put in various skills, and see if the resulting damage et c match what the skills are supposed to do.

Traditional Roguelikes (Turn Based) / Infra Arcana r7
« on: August 25, 2011, 05:26:09 PM »

Release 7 (August 25, 2011)
New features
*Save function
*Sneaking (unaware creatures are marked with an underscore)
*Backstabbing ("You stab the Cultist covertly with a dagger")
*Entry for sneaking and backstabbing in the manual
*Three new level-up bonuses to choose from
*Slot for prepared weapon (for fast switching)
*More insanity effects (including permanent effects)
*The back-story is written in the game
*Some text (e.g. insanity events) is shown in a pop-up box instead of the message log (they were too easy to miss)

*Lower monster spawn rate
*Removed hunger (the sanity system made it redundant)
*Animals listen for sound
*+1 or 2 HP when levelling up (randomly)
*More HP restored when levelling up
*Using the 'fire' command while aiming at yourself cancels the aiming mode
*Scroll of corruption can not take you to 0 HP
*Removed the "It was a scroll of" message when reading unknown scrolls
*Much higher shock from reading and identifying scrolls
*Toughness increases HP instead of decreasing damage taken
*You can no longer use the throwing attack while "Terrified"

Early Dev / Graphics concept for Infra Arcana
« on: July 15, 2011, 01:11:33 PM »
Whaddya think?

(Yeah that's three players in the top right picture)

The Nethack floor gives good contrast with many colors, but it may look out of place.

Programming / Some questions about tile graphics
« on: July 13, 2011, 11:26:16 AM »
I've been thinking about how I would implement graphics for my game, and I'm stuck on one issue.

The common way of doing creature graphics seems to be to have one image per monster, drawn so they face the viewer directly.
Like this:

And I guess that works in a game with mostly melee combat. But would it look ok with firearms? Wouldn't it look like they were shooting from their backs when firing up on the screen?

I could possibly draw characters top-down, then maybe SDL can rotate the image, or I can add rotated images myself. But I want walls from an angled perspetive, which wouldn't make sense if characters are top-down.


Version 3 of my horror/Lovecraft roguelike "Infra Arcana" is finished. I am very pleased with the recent changes, and it feels like an actual game now. :)

Game site

Changelog for Release 3

New features:
*More monsters
*Pump-action shotgun
*Monsters spawn while you are on the level
*Hit points are restored only when climbing the stairs (except for rare methods such as scrolls and potions)
*Melee weapons are classed as light, medium and heavy. When attacking there is a chance for a bonus depending on class. With light you get a free turn, heavy do maximum damage. Medium weapons get no bonus
*Varying damage (pluses) on spawned melee weapons
*When looking at melee weapons on the floor, their +damage is seen (if they have it)
*Firearms have effective range limits (half damage beyond it), the line drawn while aiming is green inside the limit and yellow beyond it
*When holding lit dynamite, the messages tells how many turns are left on the fuse
*Explosions leave smoke
*More pre-defined rooms

*Much balancing of weapons and monsters
*Changed the names of some weapons
*Fixed a bug with machine gun weapons (killing a monster caused the following bullets to hit the floor where he stood. Now machine guns are more effective against rows of monsters)
*Shotgun shells spawned on the floor can be more than one shell
*Fixed a graphical bug with gas traps
*Fixed a graphical bug with smoke
*Teleport traps are added to the "remembered" map when you are moved
*Reduced spam from Cultist anger phrases
*Death occurs on 0hp instead of -1
*Confusion is less random
*Some small improvements to the interface

Pages: [1]