Messages

1

Development Process & non-technical / Re: Independant turn based multi player

« on: May 04, 2015, 01:50:51 AM »

Yeah, or start writing a forum post about your problem. Lay out the evidence,  boil it down so it's understandable to soneone not connected to the project and by the time you've finished writing you've probably found a solution already. ^^

2

Development Process & non-technical / Re: Never played Rogue...?

« on: May 04, 2015, 01:46:53 AM »

I playey rogue once when I was  a kid but I died and then gave up.

3

Programming / Re: How to improve math skills?

« on: March 07, 2015, 12:49:56 PM »

I know where Krice is coming from with this.

I last studied math properly in high school (secondary school, I'm from the UK) and we dealt with trig and algebra and other stuff, but most of the time I was thinking "I'm never going to use any of this in real life" so I didn't bother to remember any of it beyond the final exams.

Now I sometimes find myself having to deal with things like vectors, matrix transformations and other things which I have no formal education in.
Usually if I go through a couple of code examples which show the concept in action, I can understand it through code, but I can't understand it through "math".

Dot Product

As a layman trying to understand that wiki page just gives me a headache, so I end up resorting to pages with titles like "math is fun!" Which I can actually understand pretty quickly.

Is there anywhere I can find a guide to the kind of notation I frequently run in to when looking up a complicated math concept? I'm not an idiot but I studied Fine Art in University, not Mathematics.

Or do I really need to understand the maths notation at all? When trying to write a convex hull algorithm in python I first checked the wiki page about convex hulls and got this equation which just made my eyes bleed.

But when I started reading more and got in to the algorithms I had no trouble following the steps of the pseudo code to write my own python implementation. I guess if I really knew what was going on it might help me if I made a mistake in the coding, or if I wanted to optimize my algorithm, but mainly it doesn't seem that hard to get something that works. And I don't expect I'm going to invent a better algorithm all on my own.
 

4

Development Process & non-technical / Re: A cautionary tale for aspiring roguelike programmers

« on: February 23, 2015, 03:22:45 AM »

Ha. When I was young I tried to learn programming in basic.
But it was so difficult.
Bug hunting was so horrible it was often quicker to give up and write the program over than to try to find what had gone wrong. In the end I just decided that I just wasn't a programmer.

25 years later I started again with python and I  can't believe the difference.
Easy to understand tutorials, debugging tools, text highlighting and auto completion, searchable up to date API... there's no question that it's easier to learn coding these days.

Even when I've delved in to other, slightly more complex  languages to write GLSL shaders or whatever I've found them much easier than I expected.

Anyway back on topic... 12 hours spent learning how to do something in a different programming language is only time wasted if you never use that language again. And even then you might pick up some good ideas about how to dothings differently in another language.

5

Development Process & non-technical / Re: Dungeon generator protoype

« on: December 26, 2014, 12:13:54 PM »

It looks very interesting.
I got some good ideas for my own project just by looking at the screenshots.

I'm also making a 3d graphical version of a roguelike, pretty much at the far end of the spectrum of roguelikeness, i.e. not very roguelike.
I think it's interesting to follow the arguments about what is or isn't a roguelike, it's similar in a way to other genre defining arguments, like what makes a detective story or a horror film.
Ultimately though, I think that genre conventions can be useful, but they can also be too constrictive, especially when it comes to technical considerations. In 50 years time do we still expect that roguelikes should be restricted to ascii graphics? And if we can accept roguelikes mutating to include 3d graphics engines, can we also agree that with a change in representation we might need to accept a change in gameplay? I really can't imagine that turn based gameplay is going to work very well in a first person roguelike... Perhaps at some point it requires a new break away genre to be formed, rather than another disruptive subgenre.

Anyway, on to some more useful commentary:
The map layout is good, good connectivity and the multi level sections are great.
I like the depth of field filter, though I hope it doesn't interfere with gameplay. Sometimes these kind of visual enhancements look fine for showcasing level design but don't work once you get in to gameplay.
I noticed a bit of repetition of elements in some of the smaller corridors, especially picture number 3. Do you have a way of dealing with that?

When are you thinking of making a gameplay demo? I'd suggest making that a priority. Even a reduced function demo where you run around and engage in a little combat with some simple monsters will get people to engage with the game and give you some useful feedback.

6

Design / Re: creating compelling monsters

« on: December 17, 2014, 12:02:47 PM »

Have you ever considered the ecology of the dungeon?

Google it and you'll find a whole bunch of articles for and against the idea.
For a roguelike I'm not suggesting that you have to create a food pyramid and calculate biomass or anything, but it can be cool to think about the various roles in an ecosystem which aren't filled by apex predators.

1. Plants. The bottom rung of a food chain is the plants, they get energy from the sun and disseminate it through the rest of the chain.
In a dungeon there's no sun, so we might look at other ways of absorbing energy. Mold and slimes, moss, jellies can grow underground. They don't have to be active, just passive sources of food for your wandering monsters. It gives your monsters something to do while the player isn't there too.

2. Herbivores. Sheep eat grass and wolves eat sheep. Sheep aren't aggressive, they don't attack on sight, but some herbivores can be dangerous if threatened, like a triceratops or a poisonous frog, they usually have some kind of defensive ability. How about some monsters like this? They won't attack the player unless he attacks them. Other monsters might spend their time hunting these monsters too.

3. Scavengers. There's lots of junk in a dungeon; bones, decayed flesh, metal. And there's usually a scavenger who eats it. How about a rust monster who goes around eating item drops? He won't attack you, but he might eat your gear if you leave it laying around.

So as an example:

In the dungeon a kind of mold grows which feasts on the magical energy coming from a great artifact on the lowest level. These molds are a tile feature, they can be moved through, but set of a poison effect (from their spores) if you step on them. They also have a small chance of growing in to an adjacent square each turn.
Giant centipedes eat this mold. They only eat the mold and won't attack the player unless threatened. If a giant centipede moves in to a square containing mold the mold will be eaten. Giant centipedes always move towards the nearest mold and eat it unless they are enraged in which case they move towards the nearest threat, just like a common monster.

Now you have an interesting game mechanic. If you kill the giant centipedes, perhaps for XP, or for their blood (which can make a potion of poison), the mold will begin to grow. Eventually it might begin to take up the whole level. You could keep track of the number of giant centipedes in the game and if it falls below a certain amount you could start including more mold squares in your random level generation routine further down in your dungeon.

Now you can introduce the following behavior in to your AI (while they are not attacking the player):
Giant Lizards >>attack on sight>> Giant rats >>attack on sight>>Giant Centipedes>>attack on sight>> magic mold.
Though remember to include fewer predators than prey or soon your dungeon will have only predators in it.

7

Design / Re: Adaptive Difficulty

« on: November 12, 2014, 02:49:58 PM »

Lots of games have treasure rooms with a special challenge inside or gollems or skeletons which are frozen but only attack if you mess with them, or tombstones... There's usually something you, as a player, can do to make the game more difficult if you want to.

There's an interesting question behind this issue though: Should beating a roguelike be only about gaining meta knowledge and exploiting it to reduce difficulty?

Like for example in Pixel dungeon, where there are several types of treasure room which have a special way of beating them. The room always spawns an appropriate potion to deal with the trap somewhere in the level. Once you know that, you can always beat the treasure room and scoop the reward. Once you acquire that piece of meta knowledge the game becomes instantly easier.

There are many roguelikes where you just play again and again, picking up more knowledge of exploits or shortcuts, it gets kind of boring after a while. Luck should play a part of course, but most games have some mechanic to reduce the impact of luck on player success. Like making powerful items almost useless if collected early because of level or stat restrictions on the item.

Shouldn't there be something else though? Some other factor to decide success or failure?

I enjoy playing regular RPGs, and one of the things I like most is playing through the first time on a fairly easy mode as an "ironman" mode (no save /reload loop, delete save game if I die). If I miss a side quest or do badly on a fight, or level up my charters in a suboptimal fashion, that's OK. It's kind of like life, no second chances. I love finding a puzzle which I've never encountered before and solving it with logic, not with trial and error. I love it that sometimes I can't solve the puzzle and I have to continue without getting the promised reward, simply because I wasn't smart enough. The locked chest will still be lurking there in my imagination, all the more poignant because I don't know what's inside. Later I'll go through the game again on a higher difficulty mode, try to get the stuff I missed, but it won't be quite as fun as the first time around, but theres still the element of challenge from the higher difficulty and trying to get all the secrets and side quests.

Perhaps auto adjusting difficulty has a part to play here.

How about making the game more difficult in areas where you've already had a successful play through before? That means that the game is somewhat easier in areas you're experiencing for the first time. There's more chance to make mistakes but not be brutally punished for it. While exploring new ground the game can be a little less punishing and so more enjoyable. But when you do die and have to begin from the start again, the parts of the dungeon you know well will not be a walk in the park, despite you knowing more about the monsters and traps and game mechanics. This opens up two kinds of challenges. The first time you play you're trying to make good decisions, predict monster vulnerabilities, guess which items or spells are the best look for logical places that traps might be placed, try to predict how a puzzle might be solved. The challenge is intellectual. The second time through an area you're trying to leverage your meta knowledge, pick up every advantage you can so you can get back in to unexplored territory. The challenge is more technical.

8

Design / Re: Pathfinding and Navigation.

« on: July 31, 2014, 01:23:58 PM »

Yeah, auto-play makes for a boring movie.  Or maybe a fascinating screensaver, I don't know which. 

With sufficient carefully-added randomness and logging though, it'll make a great fuzz-testing suite for finding bugs to stomp :-)

Auto-pathfind is not auto-play.  It's a way for the player to specify a play strategy at a higher level than one step at a time.  I want the player to be able to pick up a key in a room on level 6, and when she decides she wants to go back to a chest she left on level 3 to see if the key fits it, she should not have to mash a button for every square the character traverses.  That should be 'autopath - upstair' three times, then 'autopath - objects - chest'  once.  Or, depending on interface preferences, it could be a series of four mouse clicks.

If you're implementing a borg or a bot, then yes you need autopath in a way you don't for a human player.  But if the autopath is just doing strategy that the human decided on, I consider it to be the human who is the one playing the game.  Autopath doesn't (shouldn't, IMO) make decisions that matter.  If there's a single reason (ie, it matters) why a player would legitimately want to decide on one path over another, then either that decision needs to be something she can instruct the autopath system to make in her place, or she needs to not be using the autopath system.

Likewise, if on the way autopath is  interrupted six times by seeing a rat, then the player needs to decide to break off and chase them, or ignore them and keep going, or route around them as necessary, or just thwack them when they get in the way - either individually or as a pathfinding choice. If the automation serves to implement the players decisions, it's still the player's decisions that win or lose the game.  If the automation makes decisions for the player, that becomes the kind of problem you're concerned about.

That's what I meant by "fast movement", choose a destination and "warp" there but stop if you're interrupted by a monster or something else.
With a mouse controlled game it'd be easy enough, just use pathfinding to a target location.  (kind of like this: http://youtu.be/EngRPH4gs2I) You can have the movement take time, or be instantaneous. You can use visualization of the route as I did in my video or you can just give a message feedback saying that the route is valid or not. It's nice to have a route visualized before your proceed, it allows you to decide if the route that's being suggested is safe or not, and it also allows you to see if there is in fact a valid route or not.

If you're using keys only it's harder to select a route, though you could have a waypoint/signposts system where say pressing "g" for "go" will toggle waypoint movement and then you could use arrow keys to toggle through the rooms you've already visited (with a route visualization for each choice) and then press "g" again to be transported there rapidly, stopping if your route is interrupted. In that case you'd want to create and add the waypoints during level creation and make them active if certain prerequisites were met, such as all the tiles of a room being revealed, or a room being cleared of all enemies. If you've got maps which are not standard rectangular rooms you'd have to figure out a different system of way point placement, such as place a waypoint every 10 tiles in the x and y direction making a grid, if that position would place them inside a wall, find the nearest non wall square.

9

Design / Re: Pathfinding and Navigation.

« on: July 30, 2014, 11:40:20 AM »

I guess it's getting a bit off topic, the original question was how to handle Autoexplore, though there was the question of "and pathfinding".

Personally I'd never use autoplay, if you're moving automatically, picking up items automatically, and fighting automatically, are you still really playing a game, or just watching a rather dull movie? It could be an interesting programming exercise, writing your own bot program, but if you're just running the built in autoplay feature I can't see the point. Or rather I'd be asking myself "What's so boring that I have to automate it?" If some part of the game is too boring that someone can't bear to play through it manually, shouldn't it be cut from the game, or replaced with something more interesting?

However, I'm in favor of fast movement in certain situations, like if you've got designated resting/healing areas that you have to backtrack to, or dungeons are part of an overworld map and you have to go out of the dungeon to go to town and sell your items/heal/learn new skills or whatever. In that case you should be able to move almost instantly to any tile you've already discovered if there are no monsters near by and there is an unblocked path to that point. When there are large levels, I hate having to backtrack in real time to pick up some loot that I though was worthless but now need, or to look again for a key I missed or a hidden door I didn't discover.

Waypoints or signposts would be good for that, with a waypoint being inactive if an active monster is too close, or it hasn't been seen yet.

On the other hand, if you're going to use autoplay, why not make a feature of it? Instead of having a main character controlled directly by the player, how about a small number of minions with custom autoplay options. Maybe you could even enter script directly in to the game from the UI to teach your minions how to play on the fly. Maybe that'd be a good 7DRL...

10

Design / Re: Pathfinding and Navigation.

« on: July 30, 2014, 02:33:42 AM »

Are these sign posts like waypoints? That would be a fast alternative to chunk/grid based pathfinding/influence maps. Like how in 3d games grid based pathfinding is rearely used these days, instead using either polygon based walkmeshes or waypoint based navigation. I don't see any problem with using waypoint navigation in a grid based game.

You could write an algorithm to generate signposts for a map when it is created. The result would have monsters following each other around, rather than finding their own way, but it'd be a good way of reducing the resolution of influence maps or A*pathfinding.

Sounds good. Waypoints would also work well in auto explore.

11

Design / Re: Pathfinding and Navigation.

« on: July 29, 2014, 11:59:26 AM »

Using chunks for levels is definitely a design choice, it has to be in from the beginning or it's just not viable. One reason I use it is because I'm making a 3d graphical roguelike with a chunk based tileset, so it's something I've been using from the very beginning. I worked out connectivity for each possible chunk in advance so that I can do pathfinding at a lower resolution if needed. For people using a traditional 1x1 grid it's probably not going to work.

I think if your level is only 78x20 tiles you don't have to worry about the costs involved in generating influence maps or A* pathfinding.

However, something thing you could do if you're worried about the cost of generating lots of influence maps for a extra large sized level is just do a simple floodfill from the player's location. Rooms separated by a locked or closed door wouldn't need to be calculated. A floodfill could also be run once on startup and again each time a door is opened or the map changes, so you wouldn't need to do it every turn. You could also limit the number of types of influence maps generated to those required by the monsters currently in the level. If there are no stealth using monsters, you don't have to create a stealth map. As more rooms are opened, more area needs to be calculated, but by this time, there are far fewer living monsters remaining, so probably few types of map required to be generated. You could combine the flood fill with the cropped area idea to further reduce the area calculated.

For an auto explore influence map you can still do it like this, and have two different routines. One is to actively seek out and open doors (closed doors would have a high influence rating) while another would be to avoid doors. I think people might like the option of auto exploring without opening doors at first.

12

Design / Re: Pathfinding and Navigation.

« on: July 28, 2014, 04:36:03 PM »

Interesting, that's the first time I've read about the Dijkstra maps and they sound very useful, though I agree with the idea that you'd not want to calculate them for the entire dungeon every turn.

Why not consider the following:

You can use a cropped square to limit the size of your Dijkstra maps. For example if you're only calculating an area 25x25 squares around the player it'll take much less processing time than a 80x80 grid. You could limit the size of the square to just a bit larger than the player's FOV as it doesn't really matter what monsters are doing when you can't see them. Though from reading a few posts here I think different people have different ideas about simulation vs approximation, and would like to see all monsters simulated whether they are visible or not. As far as I'm concerned a monster can stand staring at a brick wall for hours on end if I can't see him doing it, but others may disagree.

You could also try breaking the map up in to sections (perhaps 5x5 squares) and get an approximation of the contents of that section. Does it have a door? Does it have friendly monsters? Does it contain the player? These sections could then form the basis for a Dijkstra map at a lower resolution than a per tile calculation. An 80x80 map would need only 16x16 Dijkstra maps in this case. If you were going to do this it'd be best to take it in to account during the level generation algorithm, so that the level is generated at a 5x5 resolution. That'd stop sections containing parts of different rooms. My own game is designed this way, though I'm using 4x4 sections. This allows me to have a large map while many of my calculations (for FOV, pathfinding, etc...) can be carried out at a lower resolution, saving processing time.

I hope to use both these methods to ensure I have fairly intelligent monsters and fast pathfinding. It's worth mentioning that the first method can also be used when using A* as it's not usually necessary to add every tile from your map in to the graph, only a bounded box that contains the agent, the target and a small border to allow for the possibility of backtracking. You can also do a simple Bresenham's line check as a prelude to an A* search to save time or you can include this in your normal LOS/FOV routine.

13

Design / Re: Identification subgame

« on: July 16, 2014, 01:47:55 PM »

Personally I prefer the idea of having a generic identify skill, or specific identify weapon, or identify wand type skills. I think the generic skill with ranks would be best. Identification could be reduced to simply using your identify skill to have a chance to identify any of the items in your inventory. Each item could then be given a flag "identify_attempted" which would only be cleared once you improve your identify skill.

I like the 'looking through' rings concept, but I think it could be part of a skill increase or event. Like for example reading a scroll tells you:

"To gain an understanding of a magical item, it is recommended to look at it through the hole in a magical ring". (Your identify skill is increased by 5 points).

Another might hint be revealed by reading an inscription on a pillar:

"Rubbing a magical sword with the scales of a common fish will reveal if it is effective against reptiles" (Your identify skill is increased by 1 point)

A scribbled not left in a drawer might tell you:

"... illegible ... but I will continue none the less... illegible... today I found that ... page missing .... the mouse quickly drank the potion and after that ..... blood from the eyes.. illegible ... must have been poison! With sadness I discarded all the ... illegible ... colored potions..." (Your identify skill is raised by 2 points)

You could write a bunch of these things and have them give a bonus to your identify skill the first time you read them. (put them in a list of learned techniques and do an "if not in learned techniques" boolean check to see if any new knowledge should trigger a skill increase.)

I think the best part of having an identify skill is that it keeps identification a going concern through out the game rather than just being an issue for the first hour of play. Imagine discovering a gilded, gem encrusted skull. It is definitely magical, but with a ID_rating of 50 you had better be playing a wizard and have invested a lot in your identify skills.

14

Programming / Re: How to avoid trashing what you've already written?

« on: July 09, 2014, 04:50:30 AM »

If you keep everything modular it shouldn't be a problem to go back and change or upgrade a module you're not happy with. I'm not really a programmer so I don't get the urge to clean my code like some people do. I don't care if it's elegant as long as it's bug free and interfaces easily with the other modules.

however I do often get the urge to change something that isn't fun or looks bad. Right now I'm rewriting my dungeon generation and tile display code. I don't know for sure the result will be better so I'm making a series of demos to test the various elements first. Some problems have already cropped up but I've also solved some issues the old system had.

15

Design / Re: I added a new monster, any ideas or feedback? (post your new stuff too)

« on: July 08, 2014, 04:25:44 PM »

What if the monsters wouldn't normally spawn by themselves, but the player would have to do something to make it happen? I have graves that might contain items and player can dig them up. But while doing so, he might end up disturbing a skeleton that will then climb out of the grave and attack the player. Later on I'm planning to have tombs of rich and powerful people to have better items and stronger monsters. That way it's not nasty surprise that the player can't control in any way, but a calculated risk.

That would work. The key is not to create a situation where the player will be unfairly penalized for something they have no control over. People hate that.
But if they chose to dig up the grave...

Other situations:
Throwing a stone down a well might disturb something.
Taking a treasure from an altar could rouse some guardians.
Picking wild mushrooms might have bad consequences.
Feeding gremlins after midnight should be avoided.
Examining an alien egg too closely is not recommended.

Maybe there should be a sign nearby to warn them of the potential consequences, or maybe make sure they get a taste of a weaker encounter before they can trigger the more deadly type of event.