Messages

16

Early Dev / Re: Demon: A monster collection roguelike

« on: November 17, 2014, 12:26:01 AM »

Runs great, adjusted to my resolution (I'm runnig it on Linux with wine). I can test a Linux build too it you make one.

I got to the level 3 (or 4), where the game got a bit tougher, and the party got killed by three red snakes and two (?)fire demons.

Some monsters, if you want then to join you, ask you to kill other monsters (zombies, for example, or that strange brownish debuffing orb - I don't remember the name), and so one encounter may immediately lead to the next.The thing is that the game is now more complex than a simple chain of independent fights, that's pretty cool.

Also, I like that you make the game look really polished.

17

Design / Re: Adaptive Difficulty

« on: November 11, 2014, 10:44:22 PM »

I'd say that the adaptive difficulty is even harder to balance than the fixed difficulty. Even if it sounds like it can make the game easier in some cases, it may also break the game entirely in some other cases, or make it not fun. Now, a player cannot be sure, whether killing a certain uber-boss was his or her real achievement, or the boss got nerfed.

Try to balance the game in such a way that an inexperinced player does not die at the same stage of the game again and again. As long as each new run brings new experience to the player, it should be fine. If the game has enough varaibility, and the difficulty progression is not too steep, even an inexperienced player will learn and get better before they got bored. If it's not enough, you may add an option to resurrect a character, or add gods or something similar to help the player when they are in trouble.

Another thing is psychological. if you want adaprive difficulty, make it the other way around. Start the game easy on the player. And then, if the player is progressing very quickly without a trouble, add difficulty, add difficult encounters, make the game nastier, make it look more bloody/gory, etc. And show this indicator of danger large and at the top of the screen, so the player will be trying to get this difficulty indicator as high as possible. Then, reaching a particularly high difficulty level would be an achievement, and that's what the player will be bragging about.. People get attrackted to such things. 

18

Programming / Re: D language - class

« on: November 11, 2014, 08:08:30 PM »

I think, the first syntax is not allowed in D to make it's grammar context free. Although, I'm not familar with D well enough to tell exactly why it is not allowed..

Also, it seems that even when creating it with new, you may allocate it in the stack rather than in the heap:
 http://www.digitalmars.com/d/archives/digitalmars/D/D2.0_Stack_allocated_classes_55100.html

19

Early Dev / Re: Wanderers / open world RL

« on: November 11, 2014, 07:52:31 PM »

Thanks a lot for playtesting! 
 

Couple of interface issues I think are worth mentioning:
* I've had a hard time telling what is going on in melee combat. I see brown numbers, red numbers, and what looks like a VFX for melee attacks, but I've had trouble figuring out what those mean, what's going on, or how a fight is going for me in general. It seems like brown numbers = I took damage, red = I dealt damage... but I'm not sure of that even after playing a few times. It also seems like I try to attack and nothing happens many times, probably a 'miss' result, but without some sort of visual feedback that isn't entirely clear.
* The "press [enter] to restart" text that appears when you die is very faint, I didn't see it for a fair bit.

I'm afraid you were trying to bump to attack. It is not explained in the game, but to attack you use WASD or Ctrl+direction. The reason for that is that multiple units may occupy the same square - this way we can get crownded streets, for example, where mobs briefly bump into each other, but keep walking in the direction they want. You can simply walk into another unit to push them, or to try to get past an enemy (it's a way to escape when you got cornered, and it may work).

The numbers tell you how much damage a unit gets. If the digit is transparent grey-ish, it's not very dangerous to the target, but when the numbers get brown and then red, it means that the target is getting siginificant damage (in short, red color component = (the damage dealt) / (remainging HP)).
The rationale is to provide some visual feedback about the HP of the target without giving their current and max HP to the player. More traditional approach is to tell HP/maxHP, but how an inexperienced firghter can tell the exact HP of a dragon?

Oh, are there plans to allow some choice over your character's initial abilities/starting gear? Especially once there's a build out with the magic stuff in it, would be cool to always be able to pick a wizard-ish start.

At the moment, your starting build is random. By looking at the Constitution (CNS) atribute, you can tell whether your characeter is strong of flimsy. Starting equipment is random too. It all depends of the starting random seed. In the future, I plan to genereate the character using their name as a seed for PRNG. So, you can get you favorite character again in a different game, if you like.

A bit more detailed info about your attributes, and how to start: README.
In short: You constitution (CNS) attribute is your max HP, also it is your mass in kilograms. Characters with high CNS also have high Athletic abilities (ATL), but worser reaction (RCT). Reaction is your average delay in units of time (0.1 second), the smaller reaction, the better.

At the moment, your attributes depend on the game's random seed. To choose the seed, you must run the game from the command line (see README) - yeah, sorry game's Linux origin, it's not in the UI yet). If you know the seed, you may start the game again with the same seed, and get the same wizard character.

I will add a few more things and make a new Windows build with magic included.

Again, thanks for playing! Hope, I answered the questions. The game is quite rough at the edges, no tutirials or in-game help, and the starting conditions can be difficult, e.g. finding your first weapon is not always easy.

20

Early Dev / Re: Demon: A monster collection roguelike

« on: November 06, 2014, 05:34:17 AM »

Yes, I think that keeping the graphics pixel perfect, but just showing a smaller region of the map would be the best solution for smaller screens, unfortunately it may require special attention to UI elements positioning (the abilities, messages, etc), and it can get tricky very quickly So, whatever you come up with is fine, there is no pressing concerns now at this stage, I think. It may become more important when you will be reaching a wider audience

21

Early Dev / Re: Demon: A monster collection roguelike

« on: November 06, 2014, 03:25:01 AM »

I played the game with Wine on Linux, so my experience may be different from native Windows execution.

The program probably could not make the window large enough, so the window turned out to be somewhat compressed vertically, and all the graphics, including the font were compressed too, see the screenshot: http://i.imgur.com/Q5biXqE.png

I liked the nice font in your screenshots actually, but I can live with the messed up font, not a big deal. I played a bit, collected some monsters, got to the second tower.

Then, I decided to switch to the fullscreen mode (by pressing F11), and after switching to the fullscreen mode the program could not get the right resolution, and switched to the worst possible, 640x480. Even after I recovered the game to the windows mode, it still tries to run in a 640x480 window, which is really not enough to play comfortably (screenshot: http://i.imgur.com/mXd2KaA.png)

Could you look at the code that handles the size of the window? My screen (1366x768) is quite standard for a laptop, and it seems to be too small for the program. Of course, I run it in emulation, but wine is pretty good usually, so maybe the native Windows computers would behave similarly in this case.

If it is possible, it would be great to do output without hard-coding the dimensions of the window, so it adjusts to the window size the player choose?

Anyway, apart form this trouble with the screen resolution, the game looks interesting. I'd like to play it more and try the fancy features like breeding. For now, I cannot really comment on the most of it, since I did only basic things. The interface is pretty intuitive. What is strange is that you don't use mouse for the controls at all, but you actually do use it for showing information when hovering over something. It's not that important now, but maybe later when you will be polishing the game, you may consider adding full mouse controls too.

22

Design / Re: Story Driven Roguelike (Based on the Hero's Journey)

« on: November 05, 2014, 07:14:53 PM »

Nice links, especially in the last message by AgingMinotaur. There must be a way to use them for procedurally generated stories. As a strating point, one can take some story they know well, and try to break it apart, describing it in terms of those typical narrative elements. It may help to see how to connect the pieces: 1) how to describe characters, objects, places, 2) how to connect the events - some sort of graph, a linear timeline of events? 3) how to take into account the personal development of each character, and how it may affect the story?

Even though it may be irrelevant to the topic, it seems to me that roguelikes usually take a bit different approach to procedural stories, at least if we look at Dwarf Fortress or URR, their authors start by creating a rich context, in which the story should (hopefully) emerge. Of course, it's not an entirely contradictory approach, but it seems more suitable for the roguelike genre, which does require this procedural world anyway. Then the story is built on top. I don't know exactly, how world generation / simulation works in Dwarf Fortress, but it seems that the history events and the map generation events interweave, so both the world and the story develop simultaneously.

23

Programming / Re: Looking for a seasoned Flash coder to give an opinion on roguelike project

« on: November 04, 2014, 10:03:38 PM »

Flash is not the most popular platform for programming roguelikes, so you should probably ask at Flash development forums/communities. And I second Rickton's suggestion to look at Haxe and OpenFL.

24

Early Dev / Re: Wanderers / open world RL

« on: November 04, 2014, 10:51:45 AM »

Hey guys! So, have you tried to play the game? Anyway, there is some new stuff.

I'm adding magic to the game. What I'm aiming for is the world where magical energy is omnipresent, flowing through the crust of the planet, through the air, through every creature and every molecule. Those who can take this energy, will be using it even if they don't know any spells.

 

Practically, there is a new characteristic, you can call it Magic affinity (MGC). It tells you how well the creature interacts with the magical energy, how it can see, absorb, and accumulate it. (~0.05 is the smallest possible value, ~1.0 is the max, meaning they peprceive and absorb it all).

The energy is accumulated as Energy points (ENG). For now, there is no fancy spellcasting per se, it will be added later, but there is its "vulgar" variant: available energy boosts your normal attacks, particularly the ranged one. When you shoot at an enemy, there is a high chance to shoot a charged bullet/bolt/arrow, it hits with significantly higher damage and momentum.
Melee attacks are boosted too, but this effect is quite unreliable. However, when fully charged with energy, boosted melee damage can be significant too, I try to make it work primarily as a desperate measure for spellcasters/archers and as an occasional attack boost for swordsmen.

The weaker (and skinnier) a mob is, the better their magical abilities are. For example, players Constitution CNS < 60 (kg) means that their are quite good spellcasters.  The video below shows how you can fight relying on magic and ranged attacks wearing almost no armor:

Real spellcasting will be added in the form of drawing sigils or magic circles on the floor, but I'm not going to add it very soon. Also, the current form of magic has to be balanced of course, but the general idea seems to be working quite well. Ranged attack is fun to play, and you don't have to be a tank to do well. Although, when I started implementing it, I wasn't sure that it would work. So, I'm quite happy about it!

I'm thinking what should be the next feature to implement. Probably, merchants and shops, or some fun AI (e.g. group behavior for mobs?), or some social stuff like reputation and rummors spreading.

25

Early Dev / Re: Wanderers / open world RL

« on: October 11, 2014, 01:44:25 AM »

jocke the beast: Thanks!

You know what, I built the game for Windows! So, please enjoy:

Download for Windows (32bit):  https://dl.dropboxusercontent.com/u/70985178/wanderers-2014-10-10.zip

The whole thing was rather non-trivial. I have VirtualBox with Win XP. There is Cygwin, MinGW toolchain, and OCaml compiler, also had to locally build SDL for MinGW. Eventually, everything did work well. Though, it took about a day. Next time it will be much easier. I'm really happy I did not run into wierd cross-compilation errors, and the Makefile did not need a lot of extra work.

I also added an option to restart the game when you die. It is more convenient particularly for Windows users who don't run programs from a terminal. Still, running from the terminal is better, b/c it gives you an option to choose the random seed for the game.


Some other updates I did a week ago, but did not post because the forum was down at the time:

1. In the last update, there are two underground biomes: Dungeons and Caves. For now, they just look different, and usually caves are deeper underground. However, I plan to add 4-6 new cave generators for this new biome. It is possible to make some mobs like caves more than dungeons, and the other way around, but I should add goblinoids first, then they will prefer caves, and the undeads will prefer dungeons.

2. There was a bug in the unit generation code. The weight of a creatures is generated from log-normal distribution, this is a good approximation of real human weights. So, once the map simulation function got stuck in an infinite loop. The reason was the following: a very light mob with weight 30kg was created, and its strength was set to a negative number. So in a fight simulation, he was running not towards, but away of the enemy, and their fight got stuck in an infinite loop.

3. Also I changed the tileset to make bricks look better, and rocks look like rocks, not like eggs/blobs. Not sure if I succeded, but let's say that this is the next iteration.

26

Design / Re: Damage reduction algorithm - looking for advice

« on: October 06, 2014, 10:03:46 PM »

I like Bear's Armor Class = divisor, it's intuitivly clear.

Let me describe one more approach, I use it in Wanderers. Each piece of armor has the property D = the probability to block an attack.
Let's say you can wear a chain mail (50%), a shield (20%), and a saber that also gives you small defense (10%).

When you equip multiple items, the combined probability is not simply added up (otherwise you could easily get >100% probability).  We add the probabilities assuming that all items block as independent events:

When two items are equipped:
50% and 20% = 50% + 20% - 50%*20% = 50% + 20% - 10% = 60%.

When three items are equipped:
50% and 20% and 10% = (50% and 20%) and 10% = 60% and 10% = 60% + 10% - 6% = 64%.

And so on, you can continue for multiple items. In general, this is called inclusion-exclusion principle, and the probability can be computed iteratively the way I just showed.

This resulting probability can be interpreted both as a chance to block, or as a factor to damage, so 60% block reduces the damage by 60%. With this approach its difficult to get very high defense, and it's impossible to become 100% immune to damage, unless you put on a 100%-blocking armor. And it fits better those games where your strength does not grow exponentially.

27

Early Dev / Re: Captive

« on: October 06, 2014, 04:19:50 PM »

I played it a few days ago, tried to play again, but the links don't work anymore.

I enjoyed the game quite a lot, until I died, when ran out of food and health potions at the ~4th level. I like the way weapons are distributed, you get the new ones exactly at the right pace, not too early and not too late. Going to the next level feels a bit tough, but some risk is also great for the game.

I wish there were a bit more food. Or maybe, if there was a clear way to play so that you save it better.

Only after playing a couple of times, I realized that I have to check the inventory every time I pick up something. Because as far as I remember, the game does not give any notifications about picked up items. I liked that you show number like (+1) or (-1), when a weapon is better or worse than your current one. However, that means that there is a simple linear progression of weapons, right?

28

Programming / Re: Writer needs Coder

« on: September 27, 2014, 06:41:35 PM »

I have never really tried CL or Scheme, but macros and quotations are what I would really like to have in my language. Though, Lisp is kind of bad for distributing the game. There are probably more options for Scheme, for exmaple Chicken Scheme that compiles to C. I don't know about weak pointer in CL, can you save a data structure with weak pointers to file, and load it back without breaking the pointers?

Btw, such data manager is not only an alternative to pointers or references. What it does, it names game objects, so it provides additional benefits.

A somewhat artificial example. A unit has the list of previous targets: [monster1, moster2, monster3]. If the elements of the list are names, you can compare, whether they were the same moster or not by comparing their names. Monster's name can be passed to another function that gives some meta information about the monster that might not be available directly from the moster itself, for example it can return the set of monster's neighbors or something like that.

29

Programming / Re: Writer needs Coder

« on: September 27, 2014, 07:15:41 AM »

It's Interesting and odd to read the comments about GM and compare them to the framework I've evolved for my own use. 
(...)

Interesting read. Yeah, it's great when a program can be nicely stratified, and all data stored in simple arrays and trees. The problem with games is that they just don't want to be nice and stratified. They are messy blobs of various interconnected things, and that is our task to put them together

Yes, different entites need to know about each other and refer to each other in some way. For example, I have regions and units. There can be a number of units at the same region. On the one hand, I want to be able to access all the units from the given region. On the other hand, each unit may need to know its current region to find where are the possible exits to the neighboring regions. Such interconnectedness arises very often. And if you avoid it, the code may degrade to a gigantic god-class or a god-function. So, we really need to connect them somehow.

What I do, is almost identical to what you describe. The game entities that need to know about each other are labeled with an ID, a simple integer. The IDs of the units are generated uniquely, so there is no possible collision. The regions have the IDs defined at the map generation stage. The units and the regions simply know each others' IDs, this is enough to link them. The objects themselves are stored in corresponding data structure, in arrays, hash tables, or maps (an O(log n) access binary tree). With a few intermediate abstraction layers, the game data is quite manageable this way. I thought about generalizing this approach somehow with a generic module, but I'm not there yet.

Actually I do have several semi-god modules that combine different things together, but I was always able to refactor and break such semi-gods apart when they were becoming too unwieldy.

30

Design / Re: Retinue - game design pitch

« on: September 27, 2014, 05:09:45 AM »

Maybe, you can first test this combat without any obstacles at all, just like in chess. Then add one pillar, then another one, and so on. Eventually, you will get the idea what works and what does not.

Because the game does not work the same way normal roguelikes do, maybe the best map is also not a dungeon with rooms and corridors, but something else?