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 - sokol815

Pages: [1]
Programming / FOV algorithm demonstration
« on: March 24, 2016, 09:07:34 PM »
I was not satisfied with the naive FOV algorithm I was using for my current RL development in javascript, so I rummaged around the roguebasin wiki and found an article titled Pre-Computed Visibility Tries. This is very similar to something I had done a little work on about 5 years ago, but hadn't gotten results I liked... so I thought I would attempt again. My last attempt involved casting rays to the perimeter of the circle instead of to the edges of a box containing the circle. This is a very subtle, but important difference. (The article explains the difference in full, so I will leave that as an exercise to the reader)

The naive algorithm, which this is replacing, involved dividing a circle into arcs of a small size. (I think I was using about 1 degree arcs), then using the obtained deltaX/deltaY from cos/sin to simulate a light beam until it reached the length of the sight radius, or hit something and died. This method was extremely expensive, requiring about 18ms to complete even when in relatively enclosed spaces. Only because it was a turn-based roguelike was it usable.

I have finished implementation of the new algorithm and found it runs at < 1ms rates for a completely open sight radius of 15(approximate area of 700 tiles) vs the old method running on a sight radius of 8(approximately 200 tiles). Most of the speed here is a massive reduction in redundant tile checking, and using a cache to store each individual ray along with distances for each tile in each ray.

I created an account on the roguebasin wiki so I could update the article with an implementation section. I further intend to write a few articles for the roguebasin wiki, as I have had quite a lot of great ideas out of reading the articles stored there.

I have a test up on my website if anyone would like to "see it in action". The code is also plainly visible to anyone who inspects the source.

javascript LOS test

Design / Experience Point cost per level
« on: October 31, 2014, 05:23:37 PM »
So, for the last 2 years or so I have been using a fairly simple method of defining how many experience points are required to reach a certain level. I thought it might be nice to share this method so others could share their thoughts.

To do this, I just set a base experience Requirement. Most commonly, I choose 5.

That means for 5 base exp, it takes 5 exp to reach level 2, 15 more to reach level 3, and 25 more to reach level 4. so by the time you hit level 4, you have gained 45 exp. each level takes 2 * base more exp to reach than the previous level.

It also happens that this method quite nicely leads to an easy total exp formula:

expReq for level n = (((n-1)^2) * baseReq) - currentTotalExp

Levels start at 1.

Total EXP required to reach a given level:

base 5 xp base 6 xp base 7 xp base 8 xp base 9 xp base 10 xp
Level 1:000000
Level 2:5678910
Level 3:202428323640
Level 4:455463728190
Level 5:8096112128144160
Level 6:125150175200225250
Level 7:180216252288324360
Level 8:245294343392441490
Level 9:320384448512576640
Level 10:405486567648729810
Level 11:5006007008009001000
Level 12:60572684796810891210
Level 13:7208641008115212961440
Level 14:84510141183135215211690
Level 15:98011761372156817641960
Level 16:112513501575180020252250
Level 17:128015361792204823042560
Level 18:144517342023231226012890
Level 19:162019442268259229163240

This has so far seemed like a decent linear increase. Of course, the amount of increase in experience needs to be gauged with the amount of experience given by a single monster. in strife, the early monsters give only 1 exp, late-game bosses/elites will(not yet implemented) eventually give up to 100 or so.

This could also easily lend itself to creating player race-types that require different amounts of exp. E.g. the troll race in ADOM requires a ton more exp relative to the grey elf race. So, in my case maybe grey elf would be 5 exp base and a troll would be 11 exp base.

If anyone is interested in seeing this system in action, head on over to strife to check it out:

Design / creating compelling monsters
« on: October 16, 2014, 02:06:25 AM »
I am working on my roguelike strife. And find myself preparing to code a more intelligent ai than my current find player, bump player routine.

monsters are responsible for a large portion of the enjoyment one gets out of a roguelike. What features make those monsters contribute most to the gameplay experience?

Some thoughts that I have gathered from around the forum and a few of my own:
  • monsters wield all items the npc can wield (what if a monster picked up an amulet of life-saving, then came back to life after you killed them!?)
  • monsters have abilities that make some challenging and others interesting (ratling duelists in ADOM, anyone? - side note, that is a great example, positive and negative effects can come from that interaction.)
  • monsters use their abilities intelligently and to great effect against the pc
  • some monsters represent a need to tactically think about your choices for how and when to defeat them. E.g. explosion on death, gathering more strength each turn, splitting gelatinous cubes, vampire weak during the day
  • monsters that trick the pc (maybe only the first time, but oh man, the feeling of being tricked... ) e.g. the classic mimic
  • monsters should not all feel 'samey'/like cookie cutter monsters
  • some monsters are just pc fodder

I'm curious to know what other thoughts and experiences you forum members have had in designing monsters that add greatly to your games, or even encounters you have had in other games.

Programming / Testing Mazing algorithms
« on: April 11, 2014, 03:11:35 PM »
Hey everyone! I have 2 different mazing algorithms that I am trying out.

Both of the below links take you to a page showing the maze being generated. The second has a restart maze option.

The first basically makes a random path until it hits a dead-end, then it will restart at the most recent terminus.

The second starts a path then randomly switches to another path that branches from a random node on the currently generated paths.

I think they both have their merits. What are your thoughts? I am leaning towards the 2nd algorithm because of all the false paths it will create.

Both mazes use a digger that has a rule where he can only move into a spot X from spot @ if a pattern is matched:

Code: [Select]
? = doesn't matter
# = wall
X = spot of interest (and is a wall)
@ = current spot

Design / need help designing your ascii interface?
« on: April 09, 2014, 08:41:07 PM »
so, a coworker just showed me this website. It is intended as a flow-chart creator, but it actually works great for making menus and pictures and such.

I thought this was pretty neat, so I decided I would share it.

the website has import and export functionality.

here is something I put together in about 30 seconds:

Code: [Select]
+––––––––––––+roguelikes rock+–––––––––+
|            +–––––––––––––––+         |
|                                      |
|                                      |
|  a short treatise on why roguelikes  |
|  are the best thing since the games  |
|  began to exist...                   |
|                                      |
|                                      |

Design / A piece-wise Magic System
« on: March 28, 2014, 12:31:56 AM »
this is a spell system I have been thinking about for at least 1 year, now.

the intent of this magic system is to make rapid-development of new magic spells easy. It also includes the bonus of providing the option to introduce piece-wise magic to the player and allow them to create their own magic spells within their game.

this system would work like so:
all spells are made up of parts, and the order of the parts dictate how the spell effects occur.
<damage> - this would be something like do 2 fire damage
<influence area>
     -default is your current position
other areas:
     -spot touching me
     -single spot
     -line terminating in spot (with bounce on walls or not)
     -arc on a circle at radius r
     -all cardinal or diagonal lines out to distance n.
     -closest non-selected enemy within distance n
     -something like apply a modifier to the entities this spell affects (like teleport, haste, heal... etc.)
     -can apply effects to the ground it lands on, as well (e.g. slow monsters that touch here within the next n turns)

then I can chain items together to create different spells
<influence:line terminating in spot, no bounce> <damage:2d5 fire damage> <effect:burned for 5 turns>
<influence:line terminating in spot, no bounce> <effect:teleport to random location>

that way I can easily just create new parts of spell effects, then they can be put together in interesting ways.
for example, the self teleport spell would be very simple:

but I could also make a teleport enemies around me spell
<influence:arc of 2PI at 1 distance><teleport>

the cost of a spell would be based upon the parts that make it up.
teleport by itself might cost merely 3mp, but adding an arc influence at distance 1 is a 20mp increase.

or I could just do that each individual piece 1, 2, 3, 4 costs a multiplier more than that which was before it. So if I wanted to deal fire damage to someone next to me, I could create a spell like:
<influence:spot touching me><fire damage><fire damage><fire damage>

then when I learn a higher level fire damage spell, I could substitute that out:
<influence:spot touching me><fire damage 2><fire damage 2><fire damage 2>

I might even be able to let the player learn different parts, then construct and save their favorite spells. This system could prove very powerful. As you can learn how to summon fire, then learn separately how to throw magic, and now you can make a fireball spell. I also think that is a lot closer to how it would work to learn new spells. Learn the pieces, put them together.

the game could still come with pre-packaged spells. It is inevitable that some sorcerers would get so advanced at creating spells that they find shortcuts to put pieces of spells together.

the more you use a specific part of a spell... e.g. fling magic in a line... the better you would get at that part... that can make things like your distance to fling, time cost, mana cost all improve.

One could also make the game even generate random spells when a new game is made!

I might also make casting time dependent upon the sum of all parts of the spell's time costs.

I think the system wouldn't be too complicated to implement, either.

I'm working on implementing this system in my jsZombie game. Which, consequently, will be greatly changed in terms of content. I'll keep everyone updated!

Anyways... back to developing!

Design / Usefulness of general math parser in your roguelike.
« on: March 23, 2014, 10:44:09 PM »
In my current roguelike project, I built a math parser which can take a string of operations and return an output.
operations: + - %(modulus) / * ^(power)  and of course ndm (e.g. 2d3)
There are a couple of use-cases that use these advanced operations to make interesting game-play.
Say I have the hammer of thor, but it's power wanes quite a bit we can say it deals "2d3^2" damage to get values of [4,9,16,25,36].  or perhaps even "2d2^1d2" for [2,3,4,9,16] damage. In the latter case, the ending portion may symbolize a critical strike or so.

%(modulus) could be useful too. Perhaps you have been cursed by a god to no longer have great power, so a %4d4 is added to all your rolls which can result in your damage getting capped. Perhaps the game will tell you "The heaven's rumble" or something like that when the modification reduces the damage you should have dealt.

Are there any other ways you guys have found of making damage more interesting?

Early Dev / Browser Based Zombie wave survival Roguelike
« on: March 19, 2014, 12:32:26 AM »
How many waves can you survive for in an endless onslaught of zombies?

You start with a handgun and a knife. Go get 'em, tiger!

Made from javascript/css/html, so it runs right in your browser!

I'd love to hear people's opinions on this one.

My personal best is dieing on wave 17
Zombies killed: 292
Total Score: 34064
Turns: 1964

    future updates will include:
    • procedurally generated map
    • more weapons - new ways of damaging enemies, like projectiles that bounce off walls, laser beams
    • armor
    • grenades
    • Zombie escalation reaction - the zombie has been kited for so long it increases in strength and speed
    • weapon skills - improve ability to use weapons with more kills DONE!
    • Magic - why not? I think it could be cool to have technology and magic intersect (80% - need more spell pieces and learning spells)
    • used damage types
    • Campaign - instead of just mindless killing, there is a story behind it.
    • Stat training/leveling system (80%)

    Also note, you can now build your own spells in this game!

I apologize for the wall of text (130 lines) that here-follows. This is a very information-packed post.

I am going to present my approach to monster generation/balancing for my current roguelike. I am curious to know how others have approached this same subject, and would love to hear suggestions others have.

my latest project is a javascript roguelike. I have been working on it for about a month now.

I had a couple of very interesting ideas to help me implement the denizens of the fateful dungeons that you would encounter in my game.

I decided I would like to use mathematical progressions like cosine and Fibonacci to create the power curves of monsters on each level.

I am using cosine as a base to calculate how many monster types and if any bosses will be on each level.
I am using Fibonacci as the basis for the power curve.

Monster Strength/Power Curve

I arbitrarily decided that I would have 20 levels in my game.

the cosine function (with some interference) generates a decent curve which allows for easier runs of levels with less varied monsters to be followed by similarly sized runs of levels with larger variety of monsters.
in my 20 levels, the equation I put together creates anywhere from 3 to 7 monster types per level with an added parameter increasing the number of monster types on later levels. any level with more than 5 monster types uses the types beyond 5 as bosses.
My current game is giving me a progression that looks like this:

level numbernumber of monster typesstrengths of monstersAverage strength*boss(es) strength*
157, 8, 9, 11, 149.8
248, 9, 10, 129.75
3311, 12, 1412.33
4412, 13, 15, 1814.5
5515, 17, 20, 25, 3322
6516, 18, 21, 26, 3423
7621, 24, 29, 37, 5032.271
8522, 25, 30, 38, 5133.2
9429, 34, 42, 5540
10430, 35, 43, 5641
11641, 49, 62, 83, 11770.4172
12658, 71, 92, 126, 181105.6270
13659, 72, 93, 127, 182106.6271
14786, 107, 141, 196, 285163429, 662
15687, 108, 142, 197, 286164430
165130, 164, 219, 308, 452254.6
176131, 165, 220, 309, 453255.6686
187200, 255, 344, 488, 721401.61098, 1708
197201, 256, 345, 489, 722402.61099, 1709
207312, 401, 545, 778, 1155638.21765, 2752

* - average strength is off because I am using a probability distribution that results in lower powered enemies being more likely to spawn than higher leveled enemies. e.g. if there were 5 enemies at strengths [7,8,9,11,14] the spawn chances would arbitrarily be [50,40,30,20,10]. This results in 5x as many level 7 enemies vs level 14 enemies

strength is generally about equal to total hitpoints for a given monster. Most other stats scale with strength as well. A strength value can generate a very generic monster, but then monster race and class are applied on-top of that generic monster to create the great variety that will exist.

I use Fibonacci as the basis for strength calculation... every couple of levels or so, I increment to the next Fibonacci as the level's base monster strength. This is visible in the nearly-always pattern of 2 levels with very similarly leveled monsters.

when a level is first created, it is populated with about 20 monsters from the table row. After a player has spent a significant amount of time on a floor, more monsters will begin to generate. These monsters follow different rules. They will instead be spawned from the pool of monsters between that level's average  * .3 to average * 1.3. as a player spends more time on a level (barring death by hunger) the additionally generated monsters creep towards a bias for stronger monsters.

Effects on gameplay & Basic Player mechanics

It becomes necessary for the player to spend some additional time on some levels or return to previous levels in order to keep up with the difficulty curve. I have always thought having to work your way towards more difficulty enemies is a fun part of roguelikes, as you see what the game can throw at you. The PC will have to be particularly powerful to advance through the later stages of the game.

A starting PC may begin with stats equivalent to a monster with strength of around 15 or 25. By the end, they will slay a boss 100 - 150x their original strength.

My intention is to make the PC rely heavily upon their gear to bring them through the final levels. A degree of crafting will be implemented in the game to achieve this balance. Crafting should eventually yield items as-powerful-as generated artifacts. Crafting is utterly useless if crafted items are of no use at the end-game.

Part of keeping the PC on their toes is making it very very difficult for them to max out their resistances. I have 6 damage types in the game (physical,cold,fire,poison,arcane,divine). A resistance of 10 means you take no damage from an attack of that type, 5 = 50%. going above 10 or below 0 makes the player recover from attack types or take extra damage from attack types.

The player shall never be able to become fully immune to physical damage, nor at any time shall the players total resistances cap 45. This will help the player to recognize the importance of tracking damage types from enemies and prepare their gear to counteract that damage.

A player can get a resistance above 10, but it would require a decent amount of gear pushing resistances for that damage type, sacrificing general resistances in the process. e.g. a rainbow or dual resistance item may offer 5 or 6 resistance by itself, but if an item offers 2 or 3 resistance to a single damage type, it is unlikely to have additional resistance modifiers.

Weapons will not be able to offer resistance bonuses, this leaves only 8 pieces of equipment from which to gain resistances (unless double-shielding, which would be 9). Therefore, no item shall ever give more than 1 physical resistance (shields and weapons 0), or more than 6 total resistance. (6 is going to be extremely difficult to achieve, even if it is distributed across all the damage types.)

Monster Races

I have also defined a set of races with accompanying monster types for those races. Each race is actually a base race, then 2 or 3 advanced or upgraded versions of that race.

here is one example:
Code: [Select]
'name':['dragon','aeldur dragon','ancient dragon'],
'description':'the {0} is a beast of magic and terrible strength',
'name':'red {0}',
'name':'blue {0}',
'name':'green {0}',
'name':'white {0}',
'name':'black {0}',
'name':['goblin','hobgoblin','greater goblin'],
'description':'{0}s are creatures of the deep, always seeking for riches',

NOTE: the '{0}' seen in some of the strings above is a placeholder, to be replaced with the basic name of the creature via string formatting. This allows for flexible enemy naming, while maintaining information about the monster in it's name. e.g. 'red {0}'.format('dragon') will return 'red dragon'

NOTE 2: the goblin family above does not yet have it's classes implemented, but I think you get the picture.

Races are chosen and ordered randomly for each game. Note the race definition at no-point defines a strength for any of the monsters. A different seed will create a different order/advancement of monster races. One game could start with goblins as the weakest enemies and dragons as the strongest, another could place them in completely opposite order.

the method of reusing a race later on as an 'upgraded race' makes for consistency in the game. you will see enemies of similar types, but much greater power.

It is possible that I may add additional parameters that make a race more likely to appear later in the game or earlier in the game based upon my notions of their strength compared to other races.

I have implemented 14 such race-definitions like the one in the code-box above. this results in about 45 different total races (some races have 4 tiers) and 225 total different enemies. Any given game currently uses about 20 different races only, so there will be great variety in which monsters you fight in each play-through. The higher leveled races of each race-definition can only appear if their lower version(s) appeared earlier in the game.

All races have different intrinsic stats that change their relative strengths if they were to be compared to another race at the same monster strength level. Dragons, for instance, tend to have more health, be resistant to damage and heal quickly. goblins, however don't have much of anything good going on for them. so a strength 50 goblin will be weaker than a strength 50 dragon because of intrinsic attributes.

When the game is choosing which monsters belong to which race, it first takes all the generated monster strengths (seen in the table above) and orders them lowest-to-highest into an array of unique values. It will then chop that array into smaller arrays of no more than 5 values where the largest value in the new array is no larger than the smaller * 1.3. This then becomes a single race. The resulting structure is power bands, where a race will always be more powerful than the race before it, but weaker than the race after it.

This organization also works well with the generated monster strengths above, as the levels tend to have mixed races of monsters. (because the values for minimum and maximum strength on a single level usually differ by much more than 30%)

Thanks for reading!

Early Dev / Exilania (renamed from Euthenia)
« on: March 18, 2013, 08:19:12 PM »
I have been working on my real-time 2d sandbox game "Exilania" now for about 10 weeks. I thought it might be nice to share some of my work with the wonderful people of rogue temple and see what you think about it!

The Exilania website can be found at

Exilania has been updated to version 0.03! lots of internal changes, a few visible were made. See my post announcing v 0.03 below.

It is basically the game I have always wanted to play. Features I have yet to implement:
  • Procedurally generated items: this includes item modifications
  • Item Crafting system: you take item-pieces (whether bought, found or salvaged) and combine them together on a 2d grid! (e.g. pickaxe head + wood handle = pickaxe)
  • Vehicle crafting: create entire vehicles from pieces available... (e.g. tanks, scooters, mechs, space ships, aircraft carriers, fighters, AT-AT  etc... whatever you can imagine!)
  • Multiplayer PVP: (multiplayer support already exists, PVP is still yet to come.)
  • Procedurally generated creatures to encounter (you want to fight a beast with 6 legs, razor sharp claws and a snout? OK!)

Systems now implemented:
  • General Materials crafting system (e.g. turn red flowers into red dye, wood into platforms... etc.)

A few random notes:
  • All graphics done by me.
  • Created in C# with XNA
  • Multiplayer LAN support (also works over the internet if you have your ports set up correctly. No NAT punch-through yet!)
  • Fullscreen mode can be whatever resolutions you choose that will fit on a single monitor.
  • windowed mode can spread across multiple monitors up to 4096 x 4096 (but only recommended for people with a fictional 16 ghz processor) works fine at 3840 x 1080. easily toggle between windowed or fullscreen mode.
  • created scripting language for "object" interactivity (e.g. wood doors, star trek automatic doors, draw bridges, turrets that track enemies, lights with sensors for when to turn on/off, power generators to power various objects... )
  • dynamic colored lighting
  • simulated liquids, including pressure

Pictures say a thousand words, right? See below:

Standing in a concrete building during the middle of the day:

full-size images: (not embedded because they are big!)

The above image:

Main menu:

Swimming in a pond:

a stone-carved castle:

Exploring a cave:

Now with Plants:

Night-Time shot:

Programming / Name Generator
« on: March 08, 2013, 04:35:43 AM »
I have always had a problem with generating names for my games. And I have never found a name generator that worked just the way I wanted. So.... I made a program that is able to generate names.

It uses Markhov chains to put together plausible groups of letters and create names.

All it requires is a word dictionary to base the chains on... I have been using a 80,000 word or so publicly available dictionary.

You can add conditions to the names (like it has mal,r or doesn't have i) and it will keep generating names until it comes up with a batch of names matching your criteria.

This is a program that I threw together today. I have seen some great things from it.

For example, I wanted to get some plausible names of resources, so I made the condition to have 'ite' in it. here are some results:
dulsite, mulenite, jacite, prambite, ascretinite, tritemy...

or evil sounding names ('mal,r') and others
glumallor, malveor, zamalar, kremald, sarmal, insaurg, kebishiz, cudshizar

alien sounding names:
poloma, koloosa, spolost, sorolow, gologum

honcology, egology, blabology, gloxidology, aeology

anyways... it is pretty darn fast for the most part (unless you are looking for groups of 5 characters in a row... then it will probably fail out)

it will even ask you if you want to save out the names you just generated to a .txt

If anyone would like to give it a whirl, I have the .exe available here:

Happy hunting! Let me know what you think about it.

Programming / Map storage compression techniques
« on: February 20, 2013, 09:04:55 PM »
I am currently writing a game that is a real-time 2d sandbox action/rpg with rogue-like elements (See 'Euthenia' on YouTube). The intent of this post is to document a successful compression technique I was able to implement to store a 10,000 x 2,500 block world (or any other size) into a file that then stores the world for later play, or prepares to send it across the network (for multiplayer servers).

each block consists of 4 physical bytes. the first 2 bytes are signed and the last two are normal bytes.

before any compression techniques, writing this world to disk resulted in a 93 Megabyte file. (And took approximately 20 seconds to write) Sending that much data across a network would take at least a few minutes, if not, longer. Applying a zipping algorithm through 7-zip brought the file size down to around 300K. Using this as a benchmark, I knew that creating any algorithm to store this would have to give me similar results.

the nature of such a 2d world is that many horizontally-adjacent blocks will be of the same type. This is where the compression algorithm could come in.

the 4 bytes per block I was writing was not fully utilized:
the 3rd byte was only using the first 2 bits (leaving 6 unused bits)
the 4th byte was using the first 7 bits. It has a max in-game value of 100 (leaving another unused bit)

these 7 unused bits could be used to store a series of blocks in a row. (127 blocks)
but because of the possibility of thousands of blocks in a row being the same (e.g. empty sky tiles)
I opted for a different method of bit utilization.

byte 4: the 8th bit is simply used as a boolean flag. When on, this says there are identical blocks after me.
byte 3: bits 3 to 7 are used as block counters, and can store a value up to 31 (meaning 31 blocks in a row)
byte 3: bit 8 is also used as a boolean flag. When on, there is a byte written after this block that also details a number of blocks in a row, except * 32 (because 31 blocks can be held in bits 3 to 7 of byte 3)

This allows me to store 31 blocks together without any additional space requirements, and I can store up to 8191 blocks (255 * 32 + 31) utilizing an additional byte.

This method of compression resulted in the same world being written to a 272KB file. So I am overall quite pleased with it (0.3% of the original filesize!) And a nice side-effect is saving the world back to a file (and reading it in) now takes less than a second.

Of course a world file will tend to creep up in size as people build objects and change the world through playing, but it is not very sizable. Someone creating a "checkerboard pattern" (this algorithm's worst enemy) of 32 x 32 blocks would result in a file size increase of merely 4KB.

Reading the world into memory is just a matter of running the algorithm the other way. How have you dealt with reading a large world in[to] a file?

Pages: [1]